[reportlab-users] reportlab-users Digest, Vol 174, Issue 2

Thu Mar 8 12:18:45 EST 2018

Please remove me from the mailing list.

-----Original Message-----
From: reportlab-users <reportlab-users-bounces at lists2.reportlab.com> On
Behalf Of reportlab-users-request at lists2.reportlab.com
Sent: Thursday, March 08, 2018 1:41 AM
To: reportlab-users at lists2.reportlab.com
Subject: reportlab-users Digest, Vol 174, Issue 2

Send reportlab-users mailing list submissions to
	reportlab-users at lists2.reportlab.com

To subscribe or unsubscribe via the World Wide Web, visit
	https://pairlist2.pair.net/mailman/listinfo/reportlab-users
or, via email, send a message with subject or body 'help' to
	reportlab-users-request at lists2.reportlab.com

You can reach the person managing the list at
	reportlab-users-owner at lists2.reportlab.com

When replying, please edit your Subject line so it is more specific than
"Re: Contents of reportlab-users digest..."

Today's Topics:

   1. Re: pdf-with-embedded-ttf-font-does-not-print (Henning von Bargen)
   2. Re: pdf-with-embedded-ttf-font-does-not-print
      (Massa, Harald Armin)
   3. Re: pdf-with-embedded-ttf-font-does-not-print (Robin Becker)
   4. Re: pdf-with-embedded-ttf-font-does-not-print (Glenn Linderman)
   5. Re: pdf-with-embedded-ttf-font-does-not-print (Tim Roberts)

----------------------------------------------------------------------

Message: 1
Date: Wed, 7 Mar 2018 08:41:14 +0000
From: Henning von Bargen <H.vonBargen at t-p.com>
To: "reportlab-users at lists2.reportlab.com"
	<reportlab-users at lists2.reportlab.com>
Subject: Re: [reportlab-users]
	pdf-with-embedded-ttf-font-does-not-print
Message-ID: <8ACB0462660EEA47A4987B90703A89A90180C3C9 at POSTIT>
Content-Type: text/plain; charset="us-ascii"

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

------------------------------

Message: 2
Date: Wed, 7 Mar 2018 09:50:25 +0100
From: "Massa, Harald Armin" <chef at ghum.de>
To: reportlab-users <reportlab-users at lists2.reportlab.com>
Subject: Re: [reportlab-users]
	pdf-with-embedded-ttf-font-does-not-print
Message-ID:
	<CAMSP2L7PeeY+V1JMyfaDwpn1zPEqVNj-2xj_afF0UJukJBxboQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2018-03-07 9:41 GMT+01:00 Henning von Bargen <H.vonBargen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20180307/3
b032707/attachment-0001.html>

------------------------------

Message: 3
Date: Wed, 7 Mar 2018 11:44:07 +0000
From: Robin Becker <robin at reportlab.com>
To: For users of Reportlab open source software
	<reportlab-users at lists2.reportlab.com>
Subject: Re: [reportlab-users]
	pdf-with-embedded-ttf-font-does-not-print
Message-ID:
	<cfc0c1bc-a216-f708-c567-4ed065639dd1 at chamonix.reportlab.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed

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

------------------------------

Message: 4
Date: Wed, 7 Mar 2018 12:41:20 -0800
From: Glenn Linderman <v+python at g.nevcal.com>
To: reportlab-users at lists2.reportlab.com
Subject: Re: [reportlab-users]
	pdf-with-embedded-ttf-font-does-not-print
Message-ID: <9c25ee4f-afb4-5b8c-98f8-e89a1f082cd3 at g.nevcal.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

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/2
b20c686/attachment-0001.html>

------------------------------

Message: 5
Date: Wed, 7 Mar 2018 12:50:31 -0800
From: Tim Roberts <timr at probo.com>
To: reportlab-users <reportlab-users at lists2.reportlab.com>
Subject: Re: [reportlab-users]
	pdf-with-embedded-ttf-font-does-not-print
Message-ID: <2b222a68-b952-6d18-b978-101f17620b9f at probo.com>
Content-Type: text/plain; charset=utf-8

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, timr at probo.com
Providenza & Boekelheide, Inc.

------------------------------

Subject: Digest Footer

_______________________________________________
reportlab-users mailing list
reportlab-users at lists2.reportlab.com
https://pairlist2.pair.net/mailman/listinfo/reportlab-users

------------------------------

End of reportlab-users Digest, Vol 174, Issue 2
***********************************************