Werner LEMBERG writes:
>>> But string handling is delegated to Pango...
>>
>> Not as far as I can see. String _typesetting_ is delegated to Pango.
>
> Ok. My knowledge of the code is too restricted. Does LilyPond itself
> check the validity of UTF-8 somewhere? Otherwise, we could reuse code
>> But string handling is delegated to Pango...
>
> Not as far as I can see. String _typesetting_ is delegated to Pango.
Ok. My knowledge of the code is too restricted. Does LilyPond itself
check the validity of UTF-8 somewhere? Otherwise, we could reuse code
from `gnulib', file `unistr/u8-c
Werner LEMBERG writes:
>> UTF-8 is Lilypond's _input_ encoding. There is no point in leaving
>> it to its backends to complain.
>
> But string handling is delegated to Pango...
Not as far as I can see. String _typesetting_ is delegated to Pango.
--
David Kastrup
> UTF-8 is Lilypond's _input_ encoding. There is no point in leaving
> it to its backends to complain.
But string handling is delegated to Pango...
Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/
Werner LEMBERG writes:
>>> For single-byte encodings, you are correct. However, the
>>> probability is *much* higher if you consider legacy two-byte
>>> encodings for CJK scripts.
>>
>> The probability of people accidentally writing two-byte encodings for
>> CJK scripts in an ASCII-based progra
>> For single-byte encodings, you are correct. However, the
>> probability is *much* higher if you consider legacy two-byte
>> encodings for CJK scripts.
>
> The probability of people accidentally writing two-byte encodings for
> CJK scripts in an ASCII-based programming language and being total
Werner LEMBERG writes:
>>> If we get an invalid UTF-8 sequence, I'm all for it. But it is not
>>> too difficult to not get invalid sequences but still have wrong
>>> output.
>>
>> Theoretically. But it is impossible to write just a single
>> non-ASCII byte without hitting an invalid sequence s
>> If we get an invalid UTF-8 sequence, I'm all for it. But it is not
>> too difficult to not get invalid sequences but still have wrong
>> output.
>
> Theoretically. But it is impossible to write just a single
> non-ASCII byte without hitting an invalid sequence since all
> non-ASCII bytes mus
Werner LEMBERG writes:
>>> How will you discern intended and unintended input? Additionally,
>>> due to FontConfig providing a fallback mechanism for missing
>>> characters, you normally don't get warnings if you are getting a
>>> `strange' letter.
>>
>> What about a "maybe error" message? Som
>> How will you discern intended and unintended input? Additionally,
>> due to FontConfig providing a fallback mechanism for missing
>> characters, you normally don't get warnings if you are getting a
>> `strange' letter.
>
> What about a "maybe error" message? Something like "you file
> doesn'
On Thu, 29 Dec 2011 20:09:12 +0100 (CET)
Werner LEMBERG wrote:
>
> Most accidental uses of other encodings can't be confused with
> valid UTF-8 characters. Maybe we could produce an error message
> that is informative enough to help the user resolve the problem
> on his own?
Werner LEMBERG writes:
> Most accidental uses of other encodings can't be confused with
> valid UTF-8 characters. Maybe we could produce an error message
> that is informative enough to help the user resolve the problem
> on his own?
>>>
>>> I don't think this is possible.
>>
>>
2011/12/29 Werner LEMBERG :
>
> Most accidental uses of other encodings can't be confused with
> valid UTF-8 characters. Maybe we could produce an error message
> that is informative enough to help the user resolve the problem
> on his own?
>>>
>>> I don't think this is possible.
>
Most accidental uses of other encodings can't be confused with
valid UTF-8 characters. Maybe we could produce an error message
that is informative enough to help the user resolve the problem
on his own?
>>
>> I don't think this is possible.
>
> Why?
How will you discern inte
Werner LEMBERG writes:
>>> Most accidental uses of other encodings can't be confused with
>>> valid UTF-8 characters. Maybe we could produce an error message
>>> that is informative enough to help the user resolve the problem on
>>> his own?
>>
>> +1
>
> I don't think this is possible.
Why?
-
>> Most accidental uses of other encodings can't be confused with
>> valid UTF-8 characters. Maybe we could produce an error message
>> that is informative enough to help the user resolve the problem on
>> his own?
>
> +1
I don't think this is possible.
Werner
___
2011/12/29 David Kastrup :
> Francisco Vila writes:
>
>> This is the most vfaq of all times. Please ensure the file is utf-8
>> encoded.
>
> Most accidental uses of other encodings can't be confused with valid
> UTF-8 characters. Maybe we could produce an error message that is
> informative enoug
Francisco Vila writes:
> This is the most vfaq of all times. Please ensure the file is utf-8
> encoded.
Most accidental uses of other encodings can't be confused with valid
UTF-8 characters. Maybe we could produce an error message that is
informative enough to help the user resolve the problem
This is the most vfaq of all times. Please ensure the file is utf-8 encoded.
El 29/12/2011 11:45, "Amund" escribió:
>
> version 2.14.2-1
>
> The following phrase is changed when typesetting.
>
> {\italic {détaché}}
>
>
> becomes
>
>
> {\italic {dЋtachЋ}}
>
>
>
version 2.14.2-1
The following phrase is changed when typesetting.
{\italic {détaché}}
becomes
{\italic {dЋtachЋ}}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
20 matches
Mail list logo
