Re: pdf-with-embedded-ttf-font-does-not-print
Glenn Linderman <[email protected]>
| Newsgroups | gmane.comp.python.reportlab.user |
|---|---|
| Message-ID | <[email protected]> |
On 3/8/2018 12:58 AM, Robin Becker wrote: > On 07/03/2018 20:41, Glenn Linderman wrote: >> On 3/7/2018 3:44 AM, Robin Becker wrote: >>> On 07/03/2018 08:50, Massa, Harald Armin wrote: >>>> 2018-03-07 9:41 GMT+01:00 Henning von Bargen <[email protected]>: >>> > ............. >> >> PDF supports a text layer. In theory, then, if the (normal) text and >> graphics layer suddenly becomes all graphics/curves due to "convert >> glyphs to curves", one could add the text layer. I believe the text >> layer was invented to allow scanned images to retain their original >> scanned characteristics, yet allow OCR program to convert even >> bitmaps to text for copy/paste/search. I don't know the details of >> how one creates the text layer, or positions the text at the >> (approximately) same positioning as the (scanned or curves) graphics >> version of the text, but the OCR programs have figured that out. Of >> course, depending on the quality of the scanned document, the text >> generated by OCR is more or less accurate. If the document were >> created with both text and (curves from glyphs) graphics layers from >> the start, it should be possible to make it 100% accurate, both in >> content and position. > ........ > I know about the text layer and I suppose that could be done to make > the text copyable, but perhaps if we had the same fonts used then > perhaps the same issue would arise in the win 10 printing. My guess is > (as Henning suggests) that this is some driver bug and is probably > related to the sub-setting we do with ttf. Well, the text layer doesn't get printed, AFAIK, so font selection for that shouldn't matter. That's not to say that the problem isn't a driver bug.