[reportlab-users] pdf-with-embedded-ttf-font-does-not-print

[Glenn Linderman]

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 <H.vonBargen at t-p.com>:
>>>
> .............
>>
>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20180308/ca45d5c2/attachment.html>