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

[Glenn Linderman]

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>:
>
>> Anyhow: a solution would be the "convert glyphes to curves", which is 
>> one
>> of the common workarounds in printing to not be required to embed the
>> fonts. The letters are converted into curves.  That may or may not 
>> increase
>> the PDF size; it makes it much more challenging to index the text 
>> inside;
>> but it makes it easier to print.
>>
>> Could there be an operation to do this in the canvas.save() of 
>> reportlab?
>> Hard thing to program, but must likely more joyfull than hunting down
>> timing issues in a multi-version and multiple-printers windows network.
>>
> .....
> It's fairly easy to convert characters to curves and then render 
> those. We have some code to do
> the conversion in reportlab/graphics/charts/testlabels.py.
>
> It would be much harder to get allthe text output points in the canvas 
> to do the right thing.
> Presumably a font that's to be glyphed would need to indicate that to 
> the code in textobject
> which would need to actually render in drawingmode and handle all the 
> other actions and text
> state changes etc etc.
>
> Assuming we could get the path rendering working there's an issue with 
> the result not being copyable
> ie the PDF renderers won't know that the paths even are text so it 
> probably isn't even selectable.

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.

How much work? I've no clue.

Is it worth it? I've no clue.

One could alternately generate 2 PDF documents, one "normal" for 
viewing/copy/paste/search and one with "convert glyhps to curves" for 
printing, but that would be more cumbersome to use, than the version 
with a text layer.

On the other hand, I vaguely recall that some programs (not sure they 
include PDF viewers) have a print option of generating graphics for 
printing, rather than sending text...

And finally, there are programs like PDFill and Universal Document 
Converter that can print from about anything, and convert to full-page 
graphics file... which would then contain no fonts. This would be in the 
nature of a workaround for the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20180307/2b20c686/attachment.html>