ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
To: ntg-context@ntg.nl
Subject: Re: Unicode question
Date: Thu, 12 Mar 2015 21:52:59 +0100	[thread overview]
Message-ID: <5501FCAB.4090706@wxs.nl> (raw)
In-Reply-To: <CAG5iGsA5sgZ0RV-7DBXGO-w8xwCzHCMzjCB+2bmFo7QsKtdhwg@mail.gmail.com>

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
___________________________________________________________________________________

      reply	other threads:[~2015-03-12 20:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12  7:48 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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5501FCAB.4090706@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).