Jump to content
You must now use your email address to sign in [click for more info] ×

Search the Community

Showing results for tags 'XML'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Affinity Support
    • News and Information
    • Frequently Asked Questions
    • Affinity Support & Questions
    • Feedback & Suggestions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • V2 Bugs found on macOS
    • V2 Bugs found on Windows
    • V2 Bugs found on iPad
    • Reports of Bugs in Affinity Version 1 applications
  • Beta Software Forums
    • 2.4 New Features and Improvements
    • Other New Bugs and Issues in the Betas
    • Beta Software Program Members Area
    • [ARCHIVE] Reports from earlier Affinity betas

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Location


Interests


Member Title

Found 8 results

  1. Out of curiosity, I attempted to import a relatively simple brochure IDML, after finishing the layout in InDesign CS5.5 just earlier today. Most of the content are small flat tables that were autofilled with text and autoformatted in InDesign by importing a well formatted XML file that matches the tag structure of the InDesign document and its tables. I'm producing this brochure with InDesign since 9 years, having done about 30 of them so far. It just works fine, in spite of the rather rudimentary XML tag support for tables in CS5.5. (Don't know about the recent InDesign versions, but working with tags within tables in CS5.5 is a p.i.t.a., and back in the day it took me quite some time and trial'n'error to figure out how InDesign XML import works with tables.) The bug: As long as there are XML tags attached to the text frames in the IDML file, all tables within those tagged text frames will remain empty, with no text whatsoever. It affects just tables, not regular text in those frames. Removing all XML tags in InDesign and re-exporting as IMDL fixes the issue, the tables are now filled with the original text. (Other issues with IDML import and tables notwithstanding at this time…) Publisher 1.8.6, Serif store version Adobe InDesign CS5.5 (German version) MacOS 10.11.6 El Capitan
  2. 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
  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. 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
  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. 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 .
  7. 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 ;)
  8. Will there be something available to maintain the xml data of a SVG directly, so it is possible to change and add object properties?
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.