* Unicode question
@ 2015-03-12 7:48 Manfred Lotz
2015-03-12 15:41 ` Ulrike Fischer
0 siblings, 1 reply; 9+ messages in thread
From: Manfred Lotz @ 2015-03-12 7:48 UTC (permalink / raw)
To: ntg-context
Hi all,
If I run this minimal example
\starttext
�
\stopluacode
\stoptext
I get
tex error > error on line 3 in file /data/tmp/u1.tex: ! String
contains an invalid utf-8 sequence
and some more lines.
The character above is:
Character: �
Character name: REPLACEMENT CHARACTER
Charblock: Specials
Category: Other symbol
Unicode: U+fffd
UTF8: 0xefbfbd
which is a valid utf8 character.
Questions:
1. Why is it considered to be invalid?
2. Are there other valid utf8 characters which are considered invalid?
Just wanting to understand.
--
Manfred
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unicode question
2015-03-12 7:48 Unicode question Manfred Lotz
@ 2015-03-12 15:41 ` Ulrike Fischer
2015-03-12 16:35 ` Arthur Reutenauer
2015-03-12 17:57 ` Manfred Lotz
0 siblings, 2 replies; 9+ messages in thread
From: Ulrike Fischer @ 2015-03-12 15:41 UTC (permalink / raw)
To: ntg-context
Am Thu, 12 Mar 2015 08:48:27 +0100 schrieb Manfred Lotz:
> Hi all,
> If I run this minimal example
>
> \starttext
>
> �
>
> \stopluacode
>
> \stoptext
>
>
> I get
>
> tex error > error on line 3 in file /data/tmp/u1.tex: ! String
> contains an invalid utf-8 sequence
>
> and some more lines.
>
>
> The character above is:
>
> Character: �
> Character name: REPLACEMENT CHARACTER
> Charblock: Specials
> Category: Other symbol
> Unicode: U+fffd
> UTF8: 0xefbfbd
>
> which is a valid utf8 character.
>
> Questions:
>
> 1. Why is it considered to be invalid?
This is not a context question/problem but related to the binary
(you would get the same error with lualatex or plain)
The luatex code contains the lines (in unistring.w)
if (val == 0xFFFD)
utf_error();
return (val);
in a function str2uni. I didn't really try to understand the code
but it looks as if 0xFFFD is used as "invalid marker": If luatex
encounters something that isn't valid utf8 it maps val to 0xFFFD and
then test against 0xFFFD to rise an error.
> 2. Are there other valid utf8 characters which are considered invalid?
The comment in the code says
/* the 5- and 6-byte UTF-8 sequences generate integers
that are outside of the valid UCS range, and therefore
unsupported
*/
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unicode question
2015-03-12 15:41 ` Ulrike Fischer
@ 2015-03-12 16:35 ` Arthur Reutenauer
2015-03-12 18:08 ` Manfred Lotz
2015-03-12 17:57 ` Manfred Lotz
1 sibling, 1 reply; 9+ messages in thread
From: Arthur Reutenauer @ 2015-03-12 16:35 UTC (permalink / raw)
To: news3, mailing list for ConTeXt users
[-- Attachment #1.1: Type: text/plain, Size: 897 bytes --]
> The luatex code contains the lines (in unistring.w)
>
> if (val == 0xFFFD)
> utf_error();
> return (val);
>
> in a function str2uni. I didn't really try to understand the code
> but it looks as if 0xFFFD is used as "invalid marker":
Interesting. This is not actually correct, U+FFFD is a valid Unicode character; it would be better to use U+FFFE or U+FFFF for that.
Note that U+FFFD is the recommended character to use when a character can't be recognised while converting to Unicode from another encoding, so its presence is usually a sign that something went wrong upstream, but I assume Manfred is aware of that.
> The comment in the code says
>
> /* the 5- and 6-byte UTF-8 sequences generate integers
>
> that are outside of the valid UCS range, and therefore
>
> unsupported
> */
That's correct, the longest valid UTF-8 sequence is 4 bytes.
Best,
Arthur
[-- Attachment #1.2: Type: text/html, Size: 1225 bytes --]
[-- Attachment #2: Type: text/plain, Size: 485 bytes --]
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unicode question
2015-03-12 15:41 ` Ulrike Fischer
2015-03-12 16:35 ` Arthur Reutenauer
@ 2015-03-12 17:57 ` Manfred Lotz
2015-03-12 18:55 ` Hans Hagen
1 sibling, 1 reply; 9+ messages in thread
From: Manfred Lotz @ 2015-03-12 17:57 UTC (permalink / raw)
To: ntg-context
On Thu, 12 Mar 2015 16:41:59 +0100
Ulrike Fischer <news3@nililand.de> wrote:
> Am Thu, 12 Mar 2015 08:48:27 +0100 schrieb Manfred Lotz:
>
> > Hi all,
> > If I run this minimal example
> >
> > \starttext
> >
> > �
> >
> > \stopluacode
> >
> > \stoptext
> >
> >
> > I get
> >
> > tex error > error on line 3 in file /data/tmp/u1.tex: ! String
> > contains an invalid utf-8 sequence
> >
> > and some more lines.
> >
> >
> > The character above is:
> >
> > Character: �
> > Character name: REPLACEMENT CHARACTER
> > Charblock: Specials
> > Category: Other symbol
> > Unicode: U+fffd
> > UTF8: 0xefbfbd
> >
> > which is a valid utf8 character.
> >
> > Questions:
> >
> > 1. Why is it considered to be invalid?
>
> This is not a context question/problem but related to the binary
> (you would get the same error with lualatex or plain)
>
Yes, I know.
> The luatex code contains the lines (in unistring.w)
>
> if (val == 0xFFFD)
> utf_error();
> return (val);
>
> in a function str2uni. I didn't really try to understand the code
> but it looks as if 0xFFFD is used as "invalid marker": If luatex
> encounters something that isn't valid utf8 it maps val to 0xFFFD and
> then test against 0xFFFD to rise an error.
>
Took me a while to find the repository but finally I got it.
> > 2. Are there other valid utf8 characters which are considered
> > invalid?
>
> The comment in the code says
>
> /* the 5- and 6-byte UTF-8 sequences generate integers
>
> that are outside of the valid UCS range, and therefore
>
> unsupported
> */
>
Well, it is called REPLACEMENT CHARACTER, and it seems that this
character will be used to replace invalid characters. Then it causes
if (val == 0xFFFD)
utf_error();
the error message
tex_error("String contains an invalid utf-8 sequence", hlp);
to be displayed.
Ok, this answers my question.
Thanks for the pointer.
--
Manfred
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unicode question
2015-03-12 16:35 ` Arthur Reutenauer
@ 2015-03-12 18:08 ` Manfred Lotz
2015-03-12 19:04 ` Hans Hagen
0 siblings, 1 reply; 9+ messages in thread
From: Manfred Lotz @ 2015-03-12 18:08 UTC (permalink / raw)
To: ntg-context
Hi Arthur,
On Thu, 12 Mar 2015 16:35:47 +0000
Arthur Reutenauer <arthur.reutenauer@normalesup.org> wrote:
> > The luatex code contains the lines (in unistring.w)
> >
> > if (val == 0xFFFD)
> > utf_error();
> > return (val);
> >
> > in a function str2uni. I didn't really try to understand the code
> > but it looks as if 0xFFFD is used as "invalid marker":
>
> Interesting. This is not actually correct, U+FFFD is a valid Unicode
> character; it would be better to use U+FFFE or U+FFFF for that.
>
> Note that U+FFFD is the recommended character to use when a character
> can't be recognised while converting to Unicode from another
> encoding, so its presence is usually a sign that something went wrong
> upstream, but I assume Manfred is aware of that.
>
Yes, I'm aware of that. So I also think that it isn't correct to use
U+FFFD for this. Your suggestion of using either U+FFFE or U+FFFF
sounds good as both are really invalid.
--
Best, Manfred
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unicode question
2015-03-12 17:57 ` Manfred Lotz
@ 2015-03-12 18:55 ` Hans Hagen
2015-03-12 20:41 ` luigi scarso
0 siblings, 1 reply; 9+ messages in thread
From: Hans Hagen @ 2015-03-12 18:55 UTC (permalink / raw)
To: mailing list for ConTeXt users
On 3/12/2015 6:57 PM, Manfred Lotz wrote:
> On Thu, 12 Mar 2015 16:41:59 +0100
> Ulrike Fischer <news3@nililand.de> wrote:
>
>> Am Thu, 12 Mar 2015 08:48:27 +0100 schrieb Manfred Lotz:
>>
>>> Hi all,
>>> If I run this minimal example
>>>
>>> \starttext
>>>
>>> �
>>>
>>> \stopluacode
>>>
>>> \stoptext
>>>
>>>
>>> I get
>>>
>>> tex error > error on line 3 in file /data/tmp/u1.tex: ! String
>>> contains an invalid utf-8 sequence
>>>
>>> and some more lines.
>>>
>>>
>>> The character above is:
>>>
>>> Character: �
>>> Character name: REPLACEMENT CHARACTER
>>> Charblock: Specials
>>> Category: Other symbol
>>> Unicode: U+fffd
>>> UTF8: 0xefbfbd
>>>
>>> which is a valid utf8 character.
>>>
>>> Questions:
>>>
>>> 1. Why is it considered to be invalid?
>>
>> This is not a context question/problem but related to the binary
>> (you would get the same error with lualatex or plain)
>>
>
> Yes, I know.
>
>> The luatex code contains the lines (in unistring.w)
>>
>> if (val == 0xFFFD)
>> utf_error();
>> return (val);
>>
>> in a function str2uni. I didn't really try to understand the code
>> but it looks as if 0xFFFD is used as "invalid marker": If luatex
>> encounters something that isn't valid utf8 it maps val to 0xFFFD and
>> then test against 0xFFFD to rise an error.
>>
>
> Took me a while to find the repository but finally I got it.
>
>
>>> 2. Are there other valid utf8 characters which are considered
>>> invalid?
>>
>> The comment in the code says
>>
>> /* the 5- and 6-byte UTF-8 sequences generate integers
>>
>> that are outside of the valid UCS range, and therefore
>>
>> unsupported
>> */
>>
>
> Well, it is called REPLACEMENT CHARACTER, and it seems that this
> character will be used to replace invalid characters. Then it causes
> if (val == 0xFFFD)
> utf_error();
>
> the error message
> tex_error("String contains an invalid utf-8 sequence", hlp);
>
> to be displayed.
>
> Ok, this answers my question.
>
> Thanks for the pointer.
it's actually a bug ... it is ok to map an invalid character in the
input to 0xFFFD, halt and continue when permitted, but the method used
in luatex thereby obscures a valid 0xFFFD in the input
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unicode question
2015-03-12 18:08 ` Manfred Lotz
@ 2015-03-12 19:04 ` Hans Hagen
0 siblings, 0 replies; 9+ messages in thread
From: Hans Hagen @ 2015-03-12 19:04 UTC (permalink / raw)
To: mailing list for ConTeXt users
On 3/12/2015 7:08 PM, Manfred Lotz wrote:
> Hi Arthur,
>
> On Thu, 12 Mar 2015 16:35:47 +0000
> Arthur Reutenauer <arthur.reutenauer@normalesup.org> wrote:
>
>>> The luatex code contains the lines (in unistring.w)
>>>
>>> if (val == 0xFFFD)
>>> utf_error();
>>> return (val);
>>>
>>> in a function str2uni. I didn't really try to understand the code
>>> but it looks as if 0xFFFD is used as "invalid marker":
>>
>> Interesting. This is not actually correct, U+FFFD is a valid Unicode
>> character; it would be better to use U+FFFE or U+FFFF for that.
>>
>> Note that U+FFFD is the recommended character to use when a character
>> can't be recognised while converting to Unicode from another
>> encoding, so its presence is usually a sign that something went wrong
>> upstream, but I assume Manfred is aware of that.
>>
>
> Yes, I'm aware of that. So I also think that it isn't correct to use
> U+FFFD for this. Your suggestion of using either U+FFFE or U+FFFF
> sounds good as both are really invalid.
it's an attempt to recover but in the process a normal 0xFFFD triggers
an error too; recovering to 0xFFFD for a really invalid input is ok as
tex does that in more cases: i expected a } so i insert one here ...
cross your fingers etc
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unicode question
2015-03-12 18:55 ` Hans Hagen
@ 2015-03-12 20:41 ` luigi scarso
2015-03-12 20:52 ` Hans Hagen
0 siblings, 1 reply; 9+ messages in thread
From: luigi scarso @ 2015-03-12 20:41 UTC (permalink / raw)
To: mailing list for ConTeXt users
[-- Attachment #1.1: Type: text/plain, Size: 1024 bytes --]
On Thu, Mar 12, 2015 at 7:55 PM, Hans Hagen <pragma@wxs.nl> wrote:
> it's actually a bug ... it is ok to map an invalid character in the input
> to 0xFFFD, halt and continue when permitted, but the method used in luatex
> thereby obscures a valid 0xFFFD in the input
>
> FFFD REPLACEMENT CHARACTER
• used to replace an incoming character whose
value is unknown or unrepresentable in
Unicode
The meaning of FFFD is not "typeset a question mark on a black box" as in �
(which depends to font in anycase so in principle it's possible to see
something completely different in a new version of the font)
but to signal something potentially wrong with a symbol that currently in
most cases is �.
Misusing the meaning is not bad di per se, but in this specific case
I think luatex is correct to be conservative and ask to the user what to do;
context --batchmode
typesets the document,
writes the messages on the log,
and ends with -1 , so an automatic agent is also alerted.
--
luigi
[-- Attachment #1.2: Type: text/html, Size: 1672 bytes --]
[-- Attachment #2: Type: text/plain, Size: 485 bytes --]
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unicode question
2015-03-12 20:41 ` luigi scarso
@ 2015-03-12 20:52 ` Hans Hagen
0 siblings, 0 replies; 9+ messages in thread
From: Hans Hagen @ 2015-03-12 20:52 UTC (permalink / raw)
To: ntg-context
On 3/12/2015 9:41 PM, luigi scarso wrote:
>
>
> On Thu, Mar 12, 2015 at 7:55 PM, Hans Hagen <pragma@wxs.nl
> <mailto:pragma@wxs.nl>> wrote:
>
> it's actually a bug ... it is ok to map an invalid character in the
> input to 0xFFFD, halt and continue when permitted, but the method
> used in luatex thereby obscures a valid 0xFFFD in the input
>
> FFFD REPLACEMENT CHARACTER
> • used to replace an incoming character whose
> value is unknown or unrepresentable in
> Unicode
the question is not what to do when an invalid character comes in, in
that case luatex can replace it by 0xFFFD and issue a error as now,
but when the input hasn't an 0xFFFD then luatex should just carry on as
0xFFFD is a *valid* character
it is quite easy for a macro package to trigger an error as
\catcode"FFFD=15
will do thatm but it's impossible for a macro package to intercept the
weird interception by luatex's input handler
> The meaning of FFFD is not "typeset a question mark on a black box" as in �
> (which depends to font in anycase so in principle it's possible to see
> something completely different in a new version of the font)
> but to signal something potentially wrong with a symbol that currently
> in most cases is �.
> Misusing the meaning is not bad di per se, but in this specific case
> I think luatex is correct to be conservative and ask to the user what to do;
> context --batchmode
> typesets the document,
> writes the messages on the log,
> and ends with -1 , so an automatic agent is also alerted.
you cannot force a user to use \batchmode and -1 would abort a wrapper
thereby leading to an invalid document; it means that luatex can never
typeset a document where char 0xFFFD is being typeset and luatex should
not be normative
not accepting 0xFFFD in the input is a bug
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-03-12 20:52 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-12 7:48 Unicode question Manfred Lotz
2015-03-12 15:41 ` Ulrike Fischer
2015-03-12 16:35 ` Arthur Reutenauer
2015-03-12 18:08 ` Manfred Lotz
2015-03-12 19:04 ` Hans Hagen
2015-03-12 17:57 ` Manfred Lotz
2015-03-12 18:55 ` Hans Hagen
2015-03-12 20:41 ` luigi scarso
2015-03-12 20:52 ` Hans Hagen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).