Language constructor

[benoitkugler]

I've tried and implemented @dominikh suggestion for a better language API.

This should be a gain for library users. The only concern I have is that we now have to use NewLanguage even on constant, obviously well formatted strings (think NewLanguage("en")).

Not sure if there is a better way. Perhaps adding a NewLanguageRaw(string) constructor which does nothing and would be inlined ?

[hajimehoshi]

I was wondering if typesetting would use the semi-standard libraries for languages and scripts.

[benoitkugler]

I was wondering if typesetting would use the semi-standard libraries for languages and scripts.

Hum.. I'm not sure what would be the complications on the various generated tables. We would need a very compelling use case.
I also note that these types are mostly internal to the package : for most users, scripts are computed from the input text, and language are constructed via strings. For advanced users, converting to our types shouldn't be very difficult, should it ?

[hajimehoshi]

I felt that redefiniting types for languages and scripts was reinventing a wheel, but this is just out of curiosity.

I also note that these types are mostly internal to the package

This is used in the public API to determine glyphs correctly, right? (e.g. specifying ar and Arab was necessary to render Arabic texts correctly)