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

mpureka

Members
  • Posts

    29
  • Joined

  • Last visited

Reputation Activity

  1. Like
    mpureka got a reaction from JohannaH in accessibility | tagged pdf support   
    Adding my support as another customer who is looking for this functionality.
  2. Like
    mpureka reacted to Dezinah in accessibility | tagged pdf support   
    The tags and reading order would be created when the PDF is exported from the source design/layout program.
    We "assign" tags in the layout, but they don't actually get created until the PDF is being exported.
    Affinity already knows how to make a PDF because any software that creates any kind of PDF must follow the international standards for PDFs called ISO 32000. Any PDF must be made to the standard so that the PDF file can be read or viewed by any brand of PDF reader. This is very common in the manufacturing and software world. It's crucial in printing as we see with out PDF/X requirements (another international standard from the ISO for press-quality PDFs).
    All Affinity has to do now is add the standards for PDF/UA ISO 14329, an extended version of the PDF standards that includes the requirements for accessibility in a PDF, such as tags and reading orders.
    They've already built their programming engine to create general PDFs, now add in the accessibility requirements. I won't be rude and say it's easy for Affinity to do that, but it's not that complicated, either. The hardest part is making the fricking PDF itself to begin with, and they've already done that.
    @sheriffderek, since you already know HTML and CSS, let me make a comparison that could help put this into perspective.
    HTML requires that standard tags be used to encase all parts of the content, like <p>, <h1>, <h2>, etc.  You can't publish a webpage without having your content tagged.
    Desktop publishing, on the other hand, has traditionally NOT required this type of tagging, unless you were specifically doing XML, SGML, or tagged content publishing. Tags and accessibility are relatively new to the graphic design industry.
    In websites, CSS is what's used to style the content, instructing a browser to take all <p> content and use Source Sans font, for example. Or take all <h1> content and color it RBG ## ## ##. Web developers design with CSS.
    CSS is directly like what we do now with our Affinity Publisher paragraph and character styles: we define how a particular portion of text will look, its font, color, alignment, size, etc. — just like CSS does in HTML.
    At this point, Publisher doesn't let us designate what tag to put on each type of text. Styles are the most convenient way to do this, as Adobe InDesign has shown for the past decade. As a graphic designer, I need to make a style for my subheadings that specifies Roboto Bold, 24 pt on 26 pt leading, left aligned, no hyphenation — and also tag it as <h2> when the PDF is exported.
    We don't put tags inside the desktop publishing layout— no accessibility tags are in the layout. Instead, we give the instructions to add the tags when the PDF is exported. (Note, this is NOT XML, which does tag the content in the layout. PDF Accessibility tags are not XML tags.)
    So Affinity needs to expand their current PDF-export utility to include accessibility tags and reading order, and then give us a way to assign the tags and control the reading order in our layouts.
    And as a bonus, they could port that utility over to Designer, giving us the ability to make accessible info graphics and small projects in that program, too.
    If Affinity did that, eat your heart out Adobe!  😁  Illustrator doesn't have a shred of accessibility in it.
    Imagine if we designers had both layout and graphics programs that could make accessible PDFs.
    Wow. Game changer for the industry.
     
    —Bevi Chagnon / PubCom.com
    Designer | Teacher | Author | Expert for Accessible Documents
    Learn about accessibility at our free blog, www.PubCom.com/blog
    US Delegate to the ISO committee for the PDF/UA standards.
    Advisor and beta tester to software companies for building accessibility tools.
     
  3. Like
    mpureka got a reaction from walt.farrell in TOC "Export as PDF Bookmarks" does not preserve heirarchy   
    I think I have "solved" this by deleting the entire TOC and then creating a new (identical as far as I know) one.
  4. Like
    mpureka reacted to chrisdwells_ in Linked Text Documents   
    Any chance this is going to be supported in future? I use Wordsflow with all my publishing clients and can't live without it. It's probably one of the main reasons I'm not able to migrate from InDesign to Affinity just yet.
  5. Like
    mpureka got a reaction from daliboroslav in Linked Text Documents   
    Adding my support for this request -- it would be extremely helpful to be able to link even to text documents, because I have a situation where I want to publish a couple of different layouts of the same text, and right now if I do that, everytime I change one, I have to go into each of the others and make the same change there.  If it was possible to link to a text file that I could update and have those changes be automatically made in my Publisher documents when I open them, that would be amazing.
  6. Like
    mpureka got a reaction from A customer Serif lost in PDF Bookmarks out of order?   
    When exporting to PDF using a set of bookmarks based on my Table of Contents, the bookmarks seem to come out okay, but they are out of order -- bookmarks for the middle of the document are at the top of the bookmark list, followed by some for the beginning, and so on.  I can't find any logical order for them right now.
    Is this a bug, or am I doing something wrong when generating these?
×
×
  • 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.