Forum Bugs

Floated <dt> elements in document with PDF/UA-1 output profile produce unexpected reading order

David J Prokopetz
When generating documents with an output profile of PDF/UA-1, using floated <dt> elements produces a reading order whereby the <dt> elements precede every other element on the page. The document's tags, however, are consistent with the source HTML, creating a large discrepancy between the document's logical structure and specified reading order. The attached documents illustrate this using Prince 14.2 (though the issue also currently affects Prince for Books, which is where I first encountered it).
  1. floated-dt-test.html3.8 kB
  2. floated-dt-test.pdf55.8 kB

Edited by David J Prokopetz

David J Prokopetz
Trying to achieve the same effect using "display: run-in" on the <dt> elements rather than "float: left" – probably the more semantically correct way to go about it, though one that would rarely be encountered in practice due to limited browser support – produces an even stranger reading order, in which some elements appear to be omitted entirely, and this one does break the document's logical structure, to boot.
  1. run-in-dt-test.html3.8 kB
  2. run-in-dt-test.pdf55.7 kB
mikeday
Thanks, we will investigate this.
mikeday
The latest build has a fix for this PDF tagging issue, thanks again for letting us know! :)
David J Prokopetz
Yes, that seems to have done it for the version with run-in dictionary terms. The version with floated dictionary terms still produces an incorrect reading order, but I guess I can just override any of those I run into with an external stylesheet if needed. Thanks!

Are there any plans to bring Prince for Books up to date with the latest regular build in the near future? As noted in the original post, I initially ran into this problem with a document we're using some of the Books-specific extensions for, so this fix isn't immediately helpful in that particular case, though it's good to know a resolution exists.