On 27/04/2015 08:43, Ross Moore wrote: > Hi Joseph, > > On 27/04/2015, at 4:19 PM, Joseph Wright wrote: > >> On 27/04/2015 00:22, Ross Moore wrote: >>>> But of course that doesn't address the problem for LaTeXt users until >>>> someone writes a suitable/comparable package (maybe someone did >>>> already, I didn't try to follow). >>> >>> I have coding for much of what is needed, using the modified pdfTeX. >>> But there is a lot that still needs to be added; e.g. PDF’s table model, >>> References, footnotes, etc. >> >> Somewhat away from the original topic, but it strikes me that building a >> tagged PDF is going to be much more problematic at the macro layer than >> at the engine level: is that fair? > > Certainly one needs help at the engine level, to build the tree > structures: what is a parent/child of what else.
Yes, I didn't mean that engine support isn't required, but that some of the more complex concepts are probably at the macro layer. You know a lot more about this than I do, but I assume that there is more to tagged PDFs than sectioning (which is relatively easy to define). For example, as a chemist I'd guess one has to worry about chemical formulae and about reference numbers to compounds. (We tend to give the latter in bold and they commonly refer to graphics representing the structures. That looks very tricky to me to express in a tagged form!) > But macros are needed to determine where new structure starts > and finishes. > Think \section and friends, list environments, \item etc. Yes, those elements seem relatively clear. As I've noted in another reply, ConTeXt MkIV has moved to a more XML-like \startitem ... \stopitem construct as the preferred way to deal with (here) items, I guess in part as that makes such things easier. As a user that's slightly more tricky: I'd say that the ideal that one item is ended by the start of the next is pretty clear :-) > Indicators must go in at a high level, before these are decomposed > into the content: letters, font-switches, etc. Again, understood and I think reasonably clear for the macro level. > In short, determining where structure is to be found is *much* harder > at the engine level; but doing the book-keeping to preserve that > structure, once known, is definitely easier when done at that level. Makes sense. One can imagine constructing a tree at the macro level but as there still needs to be some tagging I guess it doesn't help. (Can the latter be done using \specials?) > Philip Taylor is correct in thinking that such things can be > better controlled in XML. But there the author has to put in > the extra verbose markup for themselves --- hopefully with help > from some kind of interface. > However, that can involve a pretty steep learning curve anyway. > Word has had styles for decades, but how many authors actually > make proper use of them? e.g. linking one style to another, > setting space before & after, rather than just using newlines, > and inserting space runs instead of setting tabs. > How many even know of the difference between <return> and > Shift-<return> (or is it Option-<return> ) ? :-) > The point of (La)TeX is surely to allow the human author > to not worry too much about detailed structure, but still allow > sufficient hints (via the choice of environments and macros used) > that most things should be able to be worked out. That's the plan, I guess. -- Joseph Wright -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
