On Dec 6, 2007 2:48 PM, Hans Hagen wrote:
Mojca Miklavec wrote:
But generally, LuaTeX is much more suitable for such previews (only that there might be no "newshowfont" available yet - writing one is doable if you know what you're interested in).
My two cents: ConTeXt currenty uses smcp=yes,script=latn,onum=yes,liga=yes... while fontspec uses either Letters=SmallCaps Script=Latin Numbers=OldStyle Ligatures=Common or the same raw names as above. I would prefer the "human-readable" names as in fontspec, but ... well, the font calling mechanisms really need to improve in my opinion.
What fontspec achieves in one line like (copying from XeTeX list): \setmainfont[Script=Devanagari]{Sanskrit 2003} needs dozens of lines in ConTeXt (definefontfeature, define typescripts in two steps, ... brrrr)
So in case that some more features in XeTeX/LuaTeX change, do not be surprised too much ...
keep in mind that xetex and mkiv support will not be the same in all those aspects;
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 :) (At least someone needs to fight for the rights of XeTeX users :) :) :) :)
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 :(
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', ? :) :) :) (Not to be considered a serious question of course :)
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) letters=normal letters=uppercase (+case)