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

[Robin Becker]

An anonymous bitbucket user reports inability to print RL pdf with embedded ttf fonts using MS edge and or Chrome on Windows 10.

https://bitbucket.org/rptlab/reportlab/issues/132/pdf-with-embedded-ttf-font-does-not-print

I tried the PDF's that they attached and both printed fine for me from edge / chrome on my win 10 test system.

Anyone here have any suggestions about the problem / possible causes / cures etc etc?
--
Robin Becker
_______________________________________________
reportlab-users mailing list
reportl...@lists2.reportlab.com
https://pairlist2.pair.net/mailman/listinfo/reportlab-users

[Henning von Bargen]

Probably this is not a Reportlab issue at all.
I suspect an error in the MS Windows printing system or in the printer driver or in the way the applications print.

This may be related:
I am using a 3rd-party PDF printing library.
This had worked for >10 years now more or less without issues...
... until recently, when several customers complained that sometimes part of the printed output was missing, e.g. some text was missing on the pages.
The library vendor told me that the library works in such a way that the subsetted TrueType fonts (contained in the PDF) are extracted and temporarily installed on windows, then they are used to print the document using the windows APIs, then they are uninstalled again.
When printing on a network printer, one has to tell the library to wait until the printer has actually finished printing before uninstalling the TTFs again - it is NOT sufficient to wait until the print job has successfully been submitted.
This problem happens far more often when the printer is connected to Windows 2012 or newer.

I wouldn't be surprised if Edge and Chrome have the same problem.

HTH

Henning

[Massa, Harald Armin]

2018-03-07 9:41 GMT+01:00 Henning von Bargen <H.von...@t-p.com>:

Probably this is not a Reportlab issue at all.
I suspect an error in the MS Windows printing system or in the printer driver or in the way the applications print.

The library vendor told me that the library works in such a way that the subsetted TrueType fonts (contained in the PDF) are extracted and temporarily installed on windows, then they are used to print the document using the windows APIs, then they are uninstalled again.
When printing on a network printer, one has to tell the library to wait until the printer has actually finished printing before uninstalling the TTFs again - it is NOT sufficient to wait until the print job has successfully been submitted.

trusting to wait the right time for asynchronous network events is daring. And trusting that the notifications from network printers stay constant over versions is even more daring :)

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.

Cheers

Harald

 

--

GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607

Amtsgericht Stuttgart, HRB 734971

[Robin Becker]

.....
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.
--
Robin Becker

[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.von...@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.

[Tim Roberts]

Glenn Linderman wrote:
>
> PDF supports a  text layer. ....  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.

All of this to work around one application printing bug?  I can answer
that question: no.

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Robin Becker]

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.von...@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.

[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.von...@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.

[Yannick Gosteli @ PETZI]

Dear,

I experiment a similar problem and I would like to convert all my texts
to curves as suggested.
I spent time to find a way to do that, especially in the file
'reportlab/graphics/chargs/textlabels.py' as suggested below, but
without any success.
Would you mind to give me an example how to convert characters into curves?

Thank you
Yannick

Le 07. 03. 18 à 12:44, Robin Becker a écrit :

_______________________________________________

[Dinu Gherman]

I remember I did something like that maybe 10 years ago, when experimenting with customized kerning effects and had extracted and drawn glyph outlines from some TTF. I might be able to dig up that code, again, but it can take some time.

It would certainly be a funny feature for RL, but, as you say, it would make the output less accessible, especially if you care about PDF/A or what it is named.

Cheers,

Dinu