[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GUILE 2.2 progress
From: |
Han-Wen Nienhuys |
Subject: |
Re: GUILE 2.2 progress |
Date: |
Sun, 26 Jan 2020 10:32:07 +0100 |
On Sat, Jan 25, 2020 at 8:16 PM David Kastrup <address@hidden> wrote:
> > I still get
> >
> > input/regression/mozart-hrn-3.ly:31:9: error: not a markup
> >
> > #(string-append "It has been typeset and placed in the public "
>
> Frankly, that one looks like a nightmare that should not happen. Does
> it say the same for, say, #"just a string" ? And "just a string"
> (without hash mark)?
it's also an encoding problem. There is a single UTF-8 char ("für")
before the #( ) expression. The input port is UTF-8 so it assumes the
ü to be one character, so parsing the #( ) expressions starts a byte
early causing it to see #("str" var "str2"), and interpreting it as a
vector.
Files with more unicode (morgenlied) go wrong more spectacularly.
+ // This is somewhat icky: the string will in general be in utf8, but
+ // we do our own utf8 encoding and verification in the parser, so we
+ // use the no-conversion equivalent of latin1
+ SCM str = scm_from_latin1_string (c_str ());
str_port_ = scm_mkstrport (SCM_INUM0, str, SCM_OPN | SCM_RDNG, __FUNCTION__);
scm_set_port_filename_x (str_port_, ly_string2scm (name_));
we'll need to reconsider this. I think it will be easiest to construct
a new port for each # expression. We can make it a port that reads
bytes on demand from the in-memory input, but is configured encoded as
UTF-8.
> > $ gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
> > -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
> > -dAutoRotatePages=/None -dPrinted=false -sOutputFile=mozart-hrn-3.pdf
> > -c.setpdfwrite -f/tmp/lilypond-OCyOzh
> > Error: /rangecheck in /--.parsecff--
> > Operand stack:
> > false --nostringval--
>
> Pretty sure this is an encoding problem.
Yeah, the output port for the PS file must be configured as Latin1.
--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen
Re: GUILE 2.2 progress, David Kastrup, 2020/01/25
Re: GUILE 2.2 progress, Han-Wen Nienhuys, 2020/01/29
GUILE 2.2 progress, Han-Wen Nienhuys, 2020/01/26