https://bugs.freedesktop.org/show_bug.cgi?id=83108
Priority: medium
Bug ID: 83108
Assignee: [email protected]
Summary: Other: Not enough randomness when converting to PDF
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: [email protected]
Hardware: Other
Whiteboard: BSA
Status: UNCONFIRMED
Version: 4.2.4.2 release
Component: Printing and PDF export
Product: LibreOffice
Problem description:
LO seems to have a lack of randomness for glyphs when exporting to PDF.
I did create a few shell scripts that make PDF management simpler. In one of
those scripts, stamp documents with numbers:
I can select a bunch of PDFs in Dolphin. Then I get prompted to enter a
starting number. Then the shell script goes through each pdf, it splits the PDF
up into single pages. Then it uses a .odt file and replaces in there
placeholders for document number an page number. The page number of course
increases on each page, while the document number increases from PDF to PDF.
That .odt gets then converted to a PDF page and is then put over each single
page, creating a new pdf. In the end, all pages for one document get combined
together again.
This is repeated through all documents and in the end, they are then also
merged again.
However in the resulting PDF I noticed, that the numbering for the documents is
sometimes wrong. With each font that I tried always at the same page. E.g. when
I use Arial, then document 14 starts showing up as document 10 in the combined
PDF, while as single PDF it's all fine.
I asked in the #ghostscript channel for help for what the problem could be.
Chrisl explained it to me like this:
So, this is a regular problem that comes up with the PDFs exported from
Libre/OpenOffice. When you use a font to display, for example, a string like
"Page 33", it would be wasteful to embed the entire Arial font in the PDF just
for that, so applications "subset" fonts, so the only include the descriptions
for those seven glyphs. Space is a glyph, defined for each font. The exact way
that the subsets are stored varies, so I'll go with a trivial example.....
Take the first glyph "P" - the letter P is ascii code 80. So it would also be
wasteful to include 79 glyph "slots" just to get to index 80 for P.
Applications will therefore use a custom encoding so that (massively
simplifying things!) the glyph "P" will actually be in glyph slot 1 (slot zero
is special). The "a" will be slot 2 etc.....
So, in the next document, the first thing printed in Arial is actually "This
page is intentionally left blank" - the application would put the glyph "T" in
index 0. So, when you send the two PDFs to Ghostcript's pdfwrite device, it
gets the Arial font, with the "P" in index 0 for the first PDF, then it gets
Arial for the second document - but it already has an instance of Arial
defined, so uses that. It gets a reference to index 0, which is already
occupied, and thus does not need populated.
[...]
Bear with me, I'm getting to why it's a LibreOffice problem :-)
Now, Adobe document a mechanism to prevent that kind of clash, which is that
such font subsets should have a unique, random six letter prefix added to the
name. The problem is that LibreOffice always use the same seed to create these
prefixes for each document. So, for example, the prefixes are always of the
pattern AAAAAA+Arial, AAAAAB+Arial..... so they are unique within the *current*
document but not sufficiently unique to give protection from this kind of
clash.
So, from what I gather LO has too little randomness when creating PDFs and that
can then lead to collissions.
Because of, Chrisl suggested, that I first convert to .gs and then to PDF. Ever
since implementing this change (
https://github.com/sjau/pdfForts/commit/5dc4c86d741abe9fff21ff37c7539c0d749eadac#diff-02b2731ca50711cd69dc2155179b6710
) it now works as it should.
So I assume chrisl is right and that's an LO PDF export problem.
Operating System: Ubuntu
Version: 4.2.4.2 release
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
