https://bz.apache.org/ooo/show_bug.cgi?id=125012

Nandhini <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #9 from Nandhini <[email protected]> ---
Created attachment 84924
  --> https://bz.apache.org/ooo/attachment.cgi?id=84924&action=edit
PDFs showing the bug in Ooo v4.1.0 & v4.1.1 against MS Word & OOo's Print
option

I was able to successfully replicate this bug in both 4.1.0 and 4.1.1 versions
on MAC OS X Yosemite v10.10.5.

Tests: 
With the font face Time New Roman, I tried typing text that includes em, en,
and hypen.
Then, I tried the 'Export As PDF' option. It worked.

I repeated the same procedure for different font face, New Waltograph. This
time the exported PDF file had a different symbols instead of em & en.

For the font face, atlantix pro ssi & DK Crayon Crumble, the exported PDF had
empty space instead of em & en.

Last 3 font faces (New Waltograph, atlantix pro ssi & DK Crayon Crumble) are
all installed by user. So finally, I exhaustively tried all font faces that
came with OOo. It worked fine for all except the font face HeadLineA.

I tried 'Ctrl+P' and then Save As PDF instead of 'Export as PDF' for the 3 font
faces (New Waltograph, atlantix pro ssi & DK Crayon Crumble). It worked.

I tried this with MS WORD. It worked when I saved as PDF.


Summary:
Export As PDF messes up em & en for user installed font faces.

Conclusions:
I didn't experience any messes that caused variation in em & en lengths as
experienced by other users. Instead, both em & en vanished leaving empty space. 
All user installed font faces had this bug. 
Only one of the existing font face (HEadLineA) had this bug.
Only Export As PDF combined with user-installed font face had this bug. Save As
PDF worked fine.

-- 
You are receiving this mail because:
You are the assignee for the issue.

Reply via email to