[Libreoffice-bugs] [Bug 112152] Narrow No-Break Space causes PDF Error by using Font Liberation Serif

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Thu Apr 11 21:44:18 UTC 2019


https://bugs.documentfoundation.org/show_bug.cgi?id=112152

V Stuart Foote <vstuart.foote at utsa.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vstuart.foote at utsa.edu

--- Comment #8 from V Stuart Foote <vstuart.foote at utsa.edu> ---
Confirmed on Windows 10 Ent 64-bit en-US (1803) with
Version: 6.3.0.0.alpha0+ (x64)
Build ID: 74ed80b5744fdfacf9b9c3ef8ab235c64510c20d
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64 at 42, Branch:master, Time: 2019-04-11_04:13:57
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

and Adobe Acrobat CC 2019.008.20080

I created a Writer document with Liberation Sans, holding the text: 
"Text with U+202F entered:  right there." and Export it to PDF.

On initial opening of the exported PDF, Acrobat reports:

"Cannot extract the embedded font 'BAAAAA+LiberationSans'. Some characters may
not display or print correctly."

Uncompressing the PDF, for the stream "Text with U+202F entered:  right there."
shows the NBS is handled in the runs. And the font seems well described, and
the BT -> ET runs look correct. In the clip following the second run holding
Tf<12>Tj, is the NBS.

BT
56.8 724 Td /F1 12
Tf[<01>110<02>-1<0304>2<05>2<06>-2<07>-2<04>2<08>-1<05>2<09>-2<0A>8<0B>-1<0C>-1<0B>-1<0D>2<05>-5<02>6<0E>-1<04>2<02>-1<0F02>-1<10>-1<11>2<05>]TJ
ET
Q
q 0 0 0 rg
BT
200.6 724 Td /F1 12 Tf<12>Tj
ET
Q
q 0 0 0 rg
BT
203 724 Td /F1 12
Tf[<0F07>-2<13>6<08>-1<04>-5<05>2<04>2<08>-1<02>-1<0F02>-1<14>]TJ
ET
Q
Q endstream
endobj
6 0 obj
<< /Font 7 0 R /ProcSet [ /PDF /Text ] >>
endobj
7 0 obj
<< /F1 8 0 R >>
endobj
8 0 obj
<< /BaseFont /BAAAAA+LiberationSans /FirstChar 0 /FontDescriptor 9 0 R
/LastChar 20 /Subtype /TrueType /ToUnicode 10 0 R /Type /Font /Widths [ 750 610
556 500 277 277 722 222 556 722 583 556 556 610 556 333 556 277 200 556 277 ]
>>
endobj
9 0 obj
<< /Ascent 905 /CapHeight 979 /Descent -211 /Flags 4 /FontBBox [ -543 -303 1301
980 ] /FontFile2 11 0 R /FontName /BAAAAA+LiberationSans /ItalicAngle 0 /StemV
80 /Type /FontDescriptor >>
endobj
10 0 obj
<< /Length 558 >>
stream
/CIDInit/ProcSet findresource begin
12 dict begin
begincmap
/CIDSystemInfo<<
/Registry (Adobe)
/Ordering (UCS)
/Supplement 0
>> def
/CMapName/Adobe-Identity-UCS def
/CMapType 2 def
1 begincodespacerange
<00> <FF>
endcodespacerange
20 beginbfchar
<01> <0054>
<02> <0065>
<03> <0078>
<04> <0074>
<05> <0020>
<06> <0077>
<07> <0069>
<08> <0068>
<09> <0055>
<0A> <002B>
<0B> <0032>
<0C> <0030>
<0D> <0046>
<0E> <006E>
<0F> <0072>
<10> <0064>
<11> <003A>
<12> <202F>
<13> <0067>
<14> <002E>
endbfchar
endcmap
CMapName currentdict /CMap defineresource pop
end
end
endstream
endobj


Repeating steps but without the U+202F used does not error when opening in
Acrobat.

Looking at the font, the glyph #2037 uni202F is defined--but of course as a
space has no graphical feature.

So, flip a coin if this is issue with font or an issue with Acrobat too
sensitive to a single glyph.  Either way I'd lean toward NotOurBug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190411/1604044b/attachment.html>


More information about the Libreoffice-bugs mailing list