[XeTeX] Performance of ucharclasses

[Bruno Le Floch]

> There's hardly big bucks involved here.
>
> If you think you can improve the performance of this package,
> while retaining its overall structure, then the nicest way
> to do it is to write a small "wrapper" package that requires
>   ucharclass  and then patches some of its internal macros
> to work more efficiently.
> Add extra features if you like.

In that particular case, since the function involved is an internal
setup function, it seems very tricky to patch it without changing the
code of the package itself (or copying the package and changing that
code, but that's essentially equivalent).

In any case, I repeat that I have no plan of releasing and maintaining
any package related to ucharclasses. I didn't know of this package
before last week, since I only write English texts. I only looked at
it to answer a specific question that one specific user was having.

> Include comments internally about what you are doing and why;
> perhaps including an offer to the original author to include
> these "fixes" in an update, when he/she gets time to consider it.

Indeed, if the original author is happy to make changes to his
package, then he can. Actually, another member of the forum I pointed
to in my first email told me he wrote a much more thorough
reimplementation than mine, which presumably has better performance,
and he proposed it to Mike directly.

@Mike: I know that "egreg" is a good programmer, you can mostly trust
his code :).

> This way your contribution is available to everyone, without
> prejudicing whatever the original author wants to do with their
> own coding.
>
> Also, the  ucharclass  package is pretty-much as visible to a user
> as it was previously --- it still writes its own log-messages.

Well, given the semi-implicit license, I think that rewriting parts of
the package is pretty much forbidden, at least in spirit.

>> Mike should chime in here and clarify. He should also change his license
>> to
>> be more specific.
>
> I'd prefer the word 'could' to 'should' here.

I agree.

For my own packages, I tend to go for the simplest solution, LPPL,
which is a well-defined license. Certainly it has the drawback that
anyone can take my code, change it a little bit, rename it, and
distribute it, and I might not like the variant, or the variant might
be crap, or the variant might not mention me, but most of the time,
people don't do that, and even if they do, well, it's fine with me:
less maintainance to do :).

> Writing a useful package and putting it onto CTAN is doing
> the community a free service.
> There should be *no* obligation to provide more than the author
> him/herself feels comfortable with.

Agreed, completely.

Cheers,
Bruno