[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lilypond-auto] Issue 2985 in lilypond: lilypond: Umlauts and other
From: |
lilypond |
Subject: |
Re: [Lilypond-auto] Issue 2985 in lilypond: lilypond: Umlauts and other special characters incorrectly exported to PDF meta data |
Date: |
Sat, 01 Dec 2012 11:39:05 +0000 |
Updates:
Status: Accepted
Comment #13 on issue 2985 by address@hidden: lilypond: Umlauts and other
special characters incorrectly exported to PDF meta data
http://code.google.com/p/lilypond/issues/detail?id=2985
I am putting the status back from "Invalid" to "Accepted" as indeed
LilyPond produces an invalid PDF in the course of its operation. Even
though this is really the fault of GhostScript, we might have ways to
circumvent triggering this bug. One way that comes to mind would be _not_
to use Latin1 encoding ever, but rather switch between ASCII-only and
UTF16BE with BOM for pdfmarks.
The problem with that approach is that according to the GhostScript bug
database earlier versions of Ghostscript actually produced wrong XML for
the case UTF16BE. So while going ASCII/UTF16BE is an improvement for
_current_ buggy versions of Ghostscript, it is not clear that it is also an
improvement for _previous_ buggy versions of Ghostscript. At the very
least, we would need to make sure that the kind of Ghostscript we
distribute packaged with LilyPond for various platforms will behave nicer
with that encoding scheme.