LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Kastrup <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 15 May 2008 13:47:30 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
David Carlisle <[log in to unmask]> writes:

>> Any comments?
>
> Personally I think something like that sounds like a good idea, it
> should probably make a warning (at least to the log, probably console as
> well) presumably most of the time it would "just work" but if the
> "active character" implementation of the encoding is mapping that slot
> to an arbitrarily complicated TeX construct, then presumably just
> letting the character go through xetex as a native unicode character
> may do something different, and it may be better to flag that
> possibility in the log file.

My opinion is that the easiest way to do this would be to place
appropriate *.enc files or a whole inputenc.sty into the local search
path of XeTeX resp. LuaTeX.

It may be a LPPL conflict to do so since IIRC the file name is protected
rather than the whole path.

It is somewhat embarrassingly clear that the LaTeX team itself will not
be able to come up with something like that in a time frame fit for
TeXlive2008.

I would propose that we ask on the XeTeX and LuaTeX lists for help.  If
we are doing the actual folding and file layout design (one could also
use different extensions rather than different search paths), there
won't be any LPPL problems I think.

-- 
David Kastrup

ATOM RSS1 RSS2