Jump to content

Search the Community

Showing results for tags 'xml'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Affinity Support
    • News and Information
    • Affinity Support & Questions
    • Feature Requests, Suggestions & Discussions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • Report a Bug in Affinity Designer
    • Report a Bug in Affinity Photo
    • Report a Bug in Affinity Publisher
    • (Pre 1.7) Affinity Range Bugs Forums
  • Beta Software Forums
    • Affinity Designer Beta Forums
    • Affinity Photo Beta Forums
    • Affinity Publisher Beta Forums

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 8 results

  1. I make a LOT of use of InDesign's XML import capability. The granularity to which I can define character and paragraph styles that automatically get defined when importing has made my workflow faster than I ever thought possible (and I have XML records that can be scraped to build databases). If you could provide XML import in some fashion, I could fire Adobe and be perfectly happy with your product. Barring an import capability, is there any information on the Affinity File Format that has been published, or is it all proprietary? Thanks in advance for your replies
  2. It looks the Publisher is mainly oriented towards graphic designers. I did not see any places to import XML tagged text. To replace the mostly used publisher apps I see a need to import dynamic text to create catalogs and brochures. No idea if this is planned as a future extension or option, or if the focus is as mentioned before mainly for designers. Would be interesting to know. Göpf
  3. Could I request that there be a feature in Publisher to customize how XML is imported and handled based on the element tag? For instance, if I'm importing XML that contains the element tags `<a class="footnote-reference" href="#">` and `<aside epub:type="noteref">`, then the content inside each of those should be treated as a footnote reference and footnote content, respectively.
  4. Hello, it would be really awesome if AD could add a simple, generic Batch Builder that can export coordinates for Artboards and Slices and basic information for exported object layers to either JSON or XML: Any slice Coordinates Slices created from objects Stroke: Thickness, Color & Alignment Fill: Color Slices created from text frames (assuming a constant style for the entire frame) Family Weight Size Alignment Bonus points for any additional properties (everything in the contextual context toolbar and the effects panel may be of interest) That would dramatically increase the usefulness for UI design in collaboration with development teams! We're currently trying to use the Spine JSON-Export to automatically create design specs for our dev team, but the proprietary structure (origin in bottom left, anchor at center of any object, no text support) makes it kind of finicky. It's awesome that it's there, but a few more attributes would make it much more useful for us. If it's too time intensive to make a pretty JSON/XML-file, I'd also settle for Batch Builder that prints a parsable ToString()-Dump of the document tree .
  5. 1. Text import After fifteen minutes with the beta , it transpires to me, that Publisher lacks import or placement of text or table data. Even if I am an idiot and the morning is early, this essential step in digital typesetting should have jumped into my face. Not even pulling a text file from the file manager into the Publisher interface does do anything. If data import is not yet implemented into the beta, it should have been! How are users supposed to test a typesetting program without anything typed? Being an author and being a typesetter are two different professions, which do not overlap. A typesetter does not copy and paste any text. He does not write anything on his own into the layout, because it is not his name, which will be on the title of the publication. A typesetting program without data import is worthless. 2. XML Workflow If you publish a new publishing program in 2018, it's all about XML workflow. Nothing else really matters in these days and in the future. The application has to be able to import proprietary XML as well as standardized XML like DOCX, ODT and HTML. A scripting language will be needed, and this can only be Python (not Javascript as in Indesign). 3. File format .afpub To my horror, the file format .afpub itself turned out to be binary, as if we were living in 1990. It has to be a container with XML! This would have catapulted you ahead of Indesign, which does have all the other XML features apart from the indd file itself. No professional publisher will store layouts in an inaccessible file format.
  6. I think it must be possible, like in Indesign, to import content via XML or to update it. Better would be a direct API with which you get content in Publisher. Do you know what I mean? Especially with large catalogue publications it can't be insert content via copy and paste. That's 90's style ;)
  7. Will there be something available to maintain the xml data of a SVG directly, so it is possible to change and add object properties?
  8. Dear Developers, When exporting a file to SVG with text fields (ASCII art in my case) multiple spaces are written as simple consequent spaces in the XML file. Unfortunately XML, as HTML, will display these as a single space. Declaring xml:space="preserve" as you do, unfortunately does not suffice, because it works only if the string contains only spaces. A better approach would be to use non-breaking spaces: To keep the XML more readable you could code it to change from simple to non-breaking spaces only from the second consequent (included) onwards, so that normal prose would not be cluttered. Just a thought. Thank you in advance. Kind Regards, Philip
×