https://issues.apache.org/bugzilla/show_bug.cgi?id=52477
Chris Bowditch <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P5 Status|RESOLVED |REOPENED Resolution|INVALID | Severity|major |enhancement --- Comment #5 from Chris Bowditch <[email protected]> 2012-01-18 10:18:02 UTC --- I agree that making the prefix unique will make it easier for applications that process the PDF to extract or de-duplicate font resources when merging multiple PDF Files. However, the suggestion in this bug report to make the prefix random based on time introduces problems for regression testing PDFs generated by FOP, not just for the FOP project itself, but users of FOP who wish to regression test their documents. We could change FOP to make the prefix dependent on the glyphs in the subset, but that would be a lot of work. An alternative approach that will also make it easier for applications to extract or de-duplicate font resources when merging multiple PDFs is to allow FOP to fully embed the font resources in the PDF, rather than creating a subset. I believe this is possible today for a limited use-case, by specifying encoding-mode="single-byte" on the font element within the fop.xconf file. I say "limited" because that only works if no characters outside the ASCII range are required. Luis Bernardo, a new contributor to the FOP project is working on a new feature embedding-mode="full" which will fully embed the font and this will work for character ranges outside ASCII. If the font is fully embedded it will allow applications to more readily de-duplicate font resources when merging FOP generated PDF. I've re-opend this bugzilla, but as an enhancement request rather than a bug. As Mehdi stated, this isn't a bug, but rather a convenience feature. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
