#101 In PDF export, fonts do not appear on Apple Preview

closed
nobody
None
5
2014-08-22
2012-01-21
Anonymous
No

The PDF files that Xournal produces using 'Export to PDF' do not
display properly under Apple Preview on MacOS: the fonts are not
visible. PDF files produced by printing to a PDF file work fine.
Other PDF viewers seem to work fine, including, eg, Adobe Acrobat on
the Mac.

I'm using Debian's version of xournal, 0.4.6~pre20110721-1

I've attached a small test xournal file and PDF files produced in the
two different ways.

I note that the cairo rendering library had a very similar bug 4 years
ago. See, eg,
http://lists.freedesktop.org/archives/cairo-bugs/2007-June/001256.html
Since xournal has its own font subsetting code, perhaps this bug was
inherited from somewhere else.

(The bug is doubtless ultimately in Apple Preview, but it seems worth
working around.)

Workarounds: Use print to pdf rather than the built-in export, or use
a different viewer.

Discussion

  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-01-21

    Test xournal file

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-01-21

    PDF prodced via 'Export PDF'. Fonts do not appear on Apple Preview

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-01-21

    PDF produced via Print to File. Fonts do appear on Apple Preview.

     
    Last edit: Anonymous 2014-12-01
  • Nobody/Anonymous

    I, too, confirm this. It just recently happened in front of me. I know it used to happen, too, but I have not tested it in a long time. I have used Xournal for years.

    It's a workhorse for me. I agree that the problem is with Apple Preview, as Apple Acrobat Reader (or Pro) shows the typed text fine.

    The workaround to print to pdf I will try, but the Ctrl-E to make the pdf is so convenient. It preserves the file name.

    I am running Kubuntu (Debian).

    Thanks so much for Xournal!

     
  • Nobody/Anonymous

    I, too, confirm this. It just recently happened in front of me. I know it used to happen, too, but I have not tested it in a long time. I have used Xournal for years.

    It's a workhorse for me. I agree that the problem is with Apple Preview, as Apple Acrobat Reader (or Pro) shows the typed text fine.

    The workaround to print to pdf I will try, but the Ctrl-E to make the pdf is so convenient. It preserves the file name.

    I am running Kubuntu (Debian).

    Thanks so much for Xournal!

     
  • Denis Auroux

    Denis Auroux - 2012-02-22

    Thanks Dylan for reporting this! This seems annoying. However, since I have neither a Mac nor the time at the moment to look into what looks like a complicated interaction, please don't expect an imminent fix. Sorry!
    Denis

     
  • Michael Roitzsch

    I can contribute some more analysis:

    I verified the problem in the latest OS X 10.8 seed, so no magical fix from from Apple.

    When I select the line of text in Apple’s Preview and copy/paste it, this is what I get for both documents:
    test-export.pdf: 8LIUYMGOFVS[RJS\NYQTWSZIVXLIPE^]HSK
    test-print-to-pdf.pdf: The quick brown fox jumps over the lazy dog

    Interestingly, the problem also surfaces when importing test-export.pdf into Inkscape. I get the very same garbled text in the resulting Inkscape document. This is Inkscape 0.48 on the Mac.

    I don’t know if Inkscape/Linux shows the same issue, but if it does, this might help to investigate this problem.

     
  • Nobody/Anonymous

    I've just tested to import the test-export.pdf into Inkscape 0.48 on Linux. It's the same issue there; the text is garbage.

     
  • Denis Auroux

    Denis Auroux - 2012-05-17

    The testers who report on behavior under copy-pasting text from an exported PDF, or otherwise trying to extract text, are missing the point. This is a different issue from the one reported about Apple Preview.

    There are two completely different things here:

    1. how the text is encoded into PDF glyphs. This is what your copy-paste and related experiments are looking into, and it is not the issue initially reported. For Type 1 fonts, the encoding is straightforward and should not pose a problem; the issue you are now discussing should be specific to TrueType fonts. (fonts that are installed on your system as a .ttf file, rather than a .pfa or .pfb file).

    For TrueType fonts, font subsetting is needed for embedding into PDF, and the code used in "Export to PDF", adapted from libgnomeprint-2 which itself got that code from Sun Font Tools, does the subsetting by just taking glyphs as they come. This means that to print a "V" in a given TrueType font face for the first time, one adds a glyph (here "V") from the TrueType font into the PDF font, assigns it a character code (for example "A"), and then asks to display that character code. The code from libgnomeprint-2 does not generate the conversion table that would tell PDF viewers that, even though the character code is "A", it actually represents a "V". So copy-pasting that "V" will produce an "A". It appears that GtkPrint (the successor of libgnomeprint) has better font subsetting code; I don't know if it is close enough that a patch would be realistic. But once again this is not the issue reported here.

    2. whether certain PDF viewers render certain PDF fonts properly. From what I can tell, this is a bug in Apple Preview, since other PDF viewers appear to not have that issue. I do not understand what causes the difference in behavior, and why issue #2 (failure to appear in Apple Preview) would be specifically triggered by the SunFontTools / libgnomeprint-2 code used by "Export to PDF".

    Denis

     
  • Michael Roitzsch

    I understand your point about both issues being separate. I did not know that font subsetting works this way and that the garbled text on copy-paste is expected. Thanks for the clarification. I just provided all results of the experiments I could think of. If you have any ideas of other things I could try to help investigation, please let me know.

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-10-15

    FWIW, the most recent version of Evince on GNU/Linux is also unable to render fonts added in xournal and then exported to PDF. Okular displays the fonts just fine.

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-10-15

    Please disregard my previous comment re: Evince -- the problem occurred only with a single font, the TTF version of Terminus. All other fonts render fine. I can, however, confirm that fonts do not display properly in Preview on Mac OS 10.6. As others have noted, this is likely an Apple bug.

     
    Last edit: Anonymous 2014-12-04
  • Denis Auroux

    Denis Auroux - 2012-10-31

    For some reason this tracker is a spam magnet... closing it for comments, though I'm aware the bug is still there. Reopen a new tracker item if you have more to say about it.

    Denis

     
  • Denis Auroux

    Denis Auroux - 2012-10-31
    • status: open --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks