[lltx] Re: Request to mailing list XeTeX rejected

[Elie Roux]

Hello,

For your information, here is the answer of Ross, which conforts me in 
the idea of forking xunicode is the only option for it to work properly 
with LuaTeX...

-----------------------------------------------

Hello Elie,

On 25/03/2010, at 7:37 AM, Elie Roux wrote:

>> As for your imputation that  xunicode  has been abandoned, I find this
>> quite offensive. There can be many, many reasons why someone cannot
>> respond quickly to your requests for action. This is especially so
>> where the work is done voluntarily.
>>
>
> In fact, I come from the open-source community, and usually the 
> development is not done by only one person (like for 90% of TeX/LaTeX 
> development), but by a community that sends patches, remarks, etc. 
> This is what I tried to do with xunicode, and it didn't work, I'm 
> really sad you still want to keep this model, I think a lot of 
> packages would benefit from an open development. We are developping 
> all the LuaLaTeX packages like this, and we have to interact with two 
> closed-developped packages which are xunicode and microtype. Believe 
> me it's very hard and frustrating when you have a community working on 
> a project that depends on two packets for which we can't submit 
> patches or even have informations... We would benefit a lot from an 
> open development, that's why I had the idea to fork, after sending you 
> several unanswered messages...

I accept these points, but I do not accept the conclusions
that you draw.

Thinking about it further, I think you are asking for the
wrong thing.
It should *not* be necessary to change Xunicode at all.

What you want is a way to get the functionality that it
provides *for XeTeX* and have this loaded by LuaTeX.
To achieve this, all you need to do is override the check
that the package makes.
This can be done by first redefining \ifxetex , or providing
a non-\relax'd value for the XeTeX primitive that it checks for,
and any other things of this nature.
Load the package, and any others, then reinstate the original
checks so that no other XeTeX-specific package can be loaded
accidentally.


If *you* do this, and thereby force Xunicode to load --- in a
situation where I myself cannot vouch for the results that
will be obtained --- then it is *your* responsibility for
how well it works.

If *I* change my coding to allow Xunicode to be fully loaded
in a situation whereby I *cannot vouch* for the results, then
a user could reasonably assume that I have been negligent
or incompetent in my programming.

Since I do not regularly work with LuaTeX, I cannot provide
the kind of guarantees, of accurate useful packages that will
work reliably in well-defined situations, that has become
the expectation of (La)TeX users.

It is mostly for this reason that I have had misgivings about
simply adding an extra test for an engine, without really
knowing how well it would actually work, if at all.
It would certainly be negligent of me to purport to claim
that all of Xunicode's internals work seamlessly with LuaTeX,
when I have absolutely no idea about whether this is true
or not.

>
> Maybe you could reply me that I should be more patient, but the thing 
> is it's very strange to have such a development team and not to use it 
> because the model of development is unapropriate...

Freedom needs to be balanced with protection.
Most (La)TeX users have little idea about how it really works,
and need to be protected from making inappropriate choices.
(Indeed most software is this way!)

So again, I reject your assertion that the model of development
is inappropriate.

>
>> In fact my plan for xunicode --- when I get the time to do it --- is
>> to split the file into 2 (or more) parts. One will define the
>> important macros, the other will control the declarations of all the
>> Unicode entities and accent combinations. This is to enable the 2nd
>> part to be reloaded multiple times, with different values of the
>> encoding string; e.g., 'U', 'EU','EU1' or anything else. This will
>> make it much easier to adapt encodings to specific fonts, and to
>> implement fall-back actions when a font is found to be missing
>> specific characters that are required within a document. When I have
>> done this, the version number will become 1.0 .
>>
>
> That will be great... but TeXLive 2010 is approaching, and a lot of 
> users would benefit from a xunicode working with LuaTeX. You already 
> have the patch, what does prevent you from submiting it to the CTAN?

For the reasons given above, I do not accept that it is
an appropriate patch to be issued under my name.

Instead I might work on a wrapper package, named something
like  unxecode.sty , that overrides the checks in the ways
that I suggested above.
It could do so for *any* engine, or at least have options
allowing that, but still work seamlessly with XeTeX, leaving
not bad side-effects.
Furthermore it should allow other XeTeX-specific packages
to be loaded by other engines.

It would come with all kinds of warnings and disclaimers
about its use, making clear that the package-writer accepts
no responsibility whatsoever for any bad results that may occur.

> That's the point that I cannot even try to understand...

Then you are not properly balancing the responsibilities that
come with producing robust software that others will use,
expecting things to *just work* in their everyday situation.

>
>> I hope this serves adequately as the answer that you have been
>> seeking. Maybe quite soon there will be an interim update of xunicode
>> that includes a test that allows luatex to proceed. This is not the
>> only change that is "in the works".
>
> I hope so! Anyway, for TeXLive 2010, I still think it's a good idea to 
> fork if no update is available... Of course, the fork's development 
> would be open and patch submission would be gladly accepted!

I am more than happy to accept ideas and patches.
However, in my extensive experience of TeX and LaTeX programming,
almost always the actual coding is deficient even though the
intention is good. This means that I need to work very hard
to incorporate the ideas in a robust manner.

>
> Thank you,
> -- 
> Elie

Hopefully this gives you a better idea
of where I am coming from.

Best regards,

    Ross

To unsubscribe from this group, send email to lualatex-dev+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.