Mojca Miklavec wrote:
Well, to be honest, I wanted to ask you to do something similar to what you did with enco-utf :) once you finish the mkiv interface. That is, to auto-generate the list of feature mappings, so that the interface may remain the same in XeTeX as it is in LuaTeX, like \defineotflanguagesynonym[slovenian][slv] \defineotfscriptsynonym[latin][latn] then, language=dutch can switch on the ij ligature in LM in XeTeX as well :)
hm, first of all i don't want to see otf in any name of a command; today otf is the gospel but tomorrow ... after all, mkiv can have features for type one and tfm too concerning language and script names ... of course there will be some standard, and it may mean that for xetex there will be a huge list of such mappings; however, i prefer to do the xetex part once the luatex (mkiv) part is stable; then we can see what subset of functionality can be provided there; keep in mind that in luatex i can be way more tolerant with names (for instance, name:lmroman10-regular and name:lmroman10regular and name:lmroman10reg can all be supported and the same is true for features ... smallcaps Small Caps Smallcaps ...
(At least someone needs to fight for the rights of XeTeX users :) :) :) :)
sure
i more or less expect users to use one or the other engine and then become familiar with its specific interfaces
That's true when people use LaTeX :) That fame of ConTeXt (write once, use everywhere) should not be dropped at once :(
we should distinguish between typesetting related features and engine specific things; we should also keep in mind that some things simply are too different in engines which makes supporting both a pain; so, in practice there will be engine dependent features not being supported (for the sake of shareability or simply because implementing similar mechanisms takes ages); the same is true for pdftex/luatex ... of course pdftex will be supported, but take hz/protruding ... in mkiv i will completely redo that because it has different datastructures
anyhow, a next version of mkiv will support more verbose options,
script=slovenian smallcaps=true
Great :)
basically anything in the script, language and feature hashes (lowercased and de-spaced when compared)
What about ['fin2'] = 'Terminal Forms #2', ['fin3'] = 'Terminal Forms #3', ['ccmp'] = 'Glyph Composition/Decomposition', ? :) :) :)
Glyph Composition/Decomposition=true Glyph Composition/Decomposition=true Glyph Composition Decomposition=true GlyphCompositionDecomposition=true
(Not to be considered a serious question of course :)
well, it's the way smallcaps=true is handled -)
something numbers=oldstyle could be supported but i see no real reason for it since then we end up in endless lists of possibilities (given all kind of combinations)
Some examples: numbers=monospaced (+tnum) numbers=proportional (+pnum) numbers=lowercase/oldstyle (+onum) numbers=uppercase/lining (+lnum) numbers=[no]slashedzero (+zero)
too messy, esp if one wants proportional uppercase lining numbers with a slashed zero; of course one can have duplicate keys but then one also needs a negation thing ... i prefer the featuresets
letters=normal letters=uppercase (+case)
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------