bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wrong letter in title


From: Thomas Morley
Subject: Re: Wrong letter in title
Date: Mon, 1 Oct 2018 11:43:53 +0200

Am Mo., 1. Okt. 2018 um 01:37 Uhr schrieb David Kastrup <address@hidden>:
>
> Thomas Morley <address@hidden> writes:
>
> > Am So., 30. Sep. 2018 um 15:59 Uhr schrieb David Kastrup <address@hidden>:
> >
> >> Tracker issue: 5422 (https://sourceforge.net/p/testlilyissues/issues/5422/)
> >> Rietveld issue: 345090043 (https://codereview.appspot.com/345090043)
> >> Issue description:
> >>   Escape nul, cr, newline in PDF metadata
> >>
> >> I wasn't really aware that the strings remain pure 8-bit strings on
> >> input and the UTF16 interpretation is private business of the pdfmark
> >> command.  So thanks for that pointer, allowing to tackle this fairly
> >> long-known bug.
> >
> > Hi David,
> >
> > I tested your patch with a .ly-file containing
> > \header { title = "fooüČč" }
> > checking meta-data with exiftool.
> >
> > With 2.19.82:
> > Title                           : foo�Čč
> >
> > Recent master:
> > Title                           : fooüČč
> >
> > Recent master with guile-2.0.14 and the patches from branch guile-v2-work:
> > Title                           : fooüČč
> >
> > Recent master with guile-2.2.4 and the patches from branch
> > guile-v2-work and some others:
> > Title                           : ??foo?....
> >
> > Looks like a change in guile-2.2.x, so ly:encode-string-for-pdf does
> > not work as before.
>
> Well, then we should try to make it work again if possible.
>
> > But enabling the commented code in 'handle-metadata', i.e.:
> >
> > (use-modules (ice-9 iconv))
> > (use-modules (rnrs bytevectors))
> > ;;; Create DOCINFO pdfmark containing metadata
> > ;;; header fields with pdf prefix override those without the prefix
> > (define (handle-metadata header port)
> >   (define (metadata-encode val)
> >     ;; First, call ly:encode-string-for-pdf to encode the string (latin1 or
> >     ;; utf-16be), then escape all parentheses and backslashes
> >     ;;
> >     ;; NOTE: with guile-2.0+ ly:encode-string-for-pdf is not really needed 
> > and
> >     ;; could be replaced.
> >     ;; For guile-2.2.+ this is a 'must do'
> >     ;;
> >     (ps-quote
> >       (let* ((utf16be-bom #vu8(#xFE #xFF)))
> >         (string-append (bytevector->string utf16be-bom "ISO-8859-1")
> >                        (bytevector->string (string->utf16 val 'big)
> > "ISO-8859-1")))))
> > ...)
> >
> > Returns
> > Title                           : fooüČč
> > as desired.
> >
> > I tried to create something like below with a guile-v2-condition:
> >
> > (use-modules (ice-9 iconv))
> > (use-modules (rnrs bytevectors))
> > ;;; Create DOCINFO pdfmark containing metadata
> > ;;; header fields with pdf prefix override those without the prefix
> > (define (handle-metadata header port)
> >   (define (metadata-encode val)
> >     ;; First, call ly:encode-string-for-pdf to encode the string (latin1 or
> >     ;; utf-16be), then escape all parentheses and backslashes
> >     ;;
> >     ;; NOTE: with guile-2.0+ ly:encode-string-for-pdf is not really needed 
> > and
> >     ;; could be replaced.
> >     ;; For guile-2.2.+ this is a 'must do'
> >     ;;
> >     (ps-quote
> >       (if guile-v2
> >           (let* ((utf16be-bom #vu8(#xFE #xFF)))
> >             (string-append (bytevector->string utf16be-bom "ISO-8859-1")
> >                            (bytevector->string (string->utf16 val
> > 'big) "ISO-8859-1")))
> >           (ly:encode-string-for-pdf val))))
> >
> > ...)
> >
> >
> > Though, this does not work, because guile-1.8 would issue an error
> > about the unknown syntax.
>
> You can always write something like #vu8(#xFE #xFF) as a function call
> rather than as "read syntax".

Don't understand. Could you give a code-example?

> > Any chance to create something which will work in guilev1 and guilev2?
>
> I think the sane perspective would be fixing the problem where it
> appears rather than at some later point of time.

Agreed.
Though, to fix ly:encode-string-for-pdf, some C++-work is requiered,
which is beyond my capabilities.

Cheers,
  Harm



reply via email to

[Prev in Thread] Current Thread [Next in Thread]