manipulate ttf-fonts loaded with luatex
Hello,
I'm currently a bit playing around with the idea to add some support
in the (LaTeX) package "chessfss" (which handle chess fonts) for
fonts loaded with the luaotfload package. As luaotfload use the
context code to load the font I'm hoping that someone here can help
me with some of my problems.
Chess fonts are highly unstandard. The different authors of the
fonts did put the chars quite randomly in the character table and
also used various glyphs name. So in the psfonts.map almost every
font has its own encoding vector:
chess-pirat-lsf ChessFigurinePirat " ChessPiratFigEncoding
ReEncodeFont "
On Wed, 27 Oct 2010, Ulrike Fischer wrote:
Hello,
I'm currently a bit playing around with the idea to add some support in the (LaTeX) package "chessfss" (which handle chess fonts) for fonts loaded with the luaotfload package. As luaotfload use the context code to load the font I'm hoping that someone here can help me with some of my problems.
Chess fonts are highly unstandard. The different authors of the fonts did put the chars quite randomly in the character table and also used various glyphs name. So in the psfonts.map almost every font has its own encoding vector:
What is the unicode support for chess fonts. Are there unicode glyphs for each symbol (just like card suits, I guess)? Aditya
Am Wed, 27 Oct 2010 14:35:46 -0400 (EDT) schrieb Aditya Mahajan:
On Wed, 27 Oct 2010, Ulrike Fischer wrote:
Hello,
I'm currently a bit playing around with the idea to add some support in the (LaTeX) package "chessfss" (which handle chess fonts) for fonts loaded with the luaotfload package. As luaotfload use the context code to load the font I'm hoping that someone here can help me with some of my problems.
Chess fonts are highly unstandard. The different authors of the fonts did put the chars quite randomly in the character table and also used various glyphs name. So in the psfonts.map almost every font has its own encoding vector:
What is the unicode support for chess fonts. Are there unicode glyphs for each symbol (just like card suits, I guess)?
There are unicode code points only for a part of the symbols. -- Ulrike Fischer
On Wed, 27 Oct 2010, Ulrike Fischer wrote:
Am Wed, 27 Oct 2010 14:35:46 -0400 (EDT) schrieb Aditya Mahajan:
On Wed, 27 Oct 2010, Ulrike Fischer wrote:
Hello,
I'm currently a bit playing around with the idea to add some support in the (LaTeX) package "chessfss" (which handle chess fonts) for fonts loaded with the luaotfload package. As luaotfload use the context code to load the font I'm hoping that someone here can help me with some of my problems.
Chess fonts are highly unstandard. The different authors of the fonts did put the chars quite randomly in the character table and also used various glyphs name. So in the psfonts.map almost every font has its own encoding vector:
What is the unicode support for chess fonts. Are there unicode glyphs for each symbol (just like card suits, I guess)?
There are unicode code points only for a part of the symbols.
I checked the unicode list. The codepoints 0x2654 to 0x365F cover all the chess pieces. All the fonts in enpassent.dk and chessfss_gallery.pdf show only these symbols. So what is missing? I am guessing that the problem is not as simple as just mapping a font glyph to the corresponding unicode codepoint. Aditya
Am Wed, 27 Oct 2010 17:32:21 -0400 (EDT) schrieb Aditya Mahajan:
On Wed, 27 Oct 2010, Ulrike Fischer wrote:
Am Wed, 27 Oct 2010 14:35:46 -0400 (EDT) schrieb Aditya Mahajan:
On Wed, 27 Oct 2010, Ulrike Fischer wrote:
Hello,
I'm currently a bit playing around with the idea to add some support in the (LaTeX) package "chessfss" (which handle chess fonts) for fonts loaded with the luaotfload package. As luaotfload use the context code to load the font I'm hoping that someone here can help me with some of my problems.
Chess fonts are highly unstandard. The different authors of the fonts did put the chars quite randomly in the character table and also used various glyphs name. So in the psfonts.map almost every font has its own encoding vector:
What is the unicode support for chess fonts. Are there unicode glyphs for each symbol (just like card suits, I guess)?
There are unicode code points only for a part of the symbols.
I checked the unicode list. The codepoints 0x2654 to 0x365F cover all the chess pieces. All the fonts in enpassent.dk and chessfss_gallery.pdf show only these symbols. So what is missing?
Most of the symbols needed/used by chessfss to construct boards: WhiteKingOnBlack, BlackQueenOnBlack etc, piecemasks and fieldmasks. Also a lot of so-called "informator symbols" used to comment chess games. If you want to see the whole range of symbol look in the skaknew-fonts on CTAN. They are quite complete.
I am guessing that the problem is not as simple as just mapping a font glyph to the corresponding unicode codepoint.
Even if unicode would have a code point for every symbol: At first my problem is not _where_ to map a glyph but _how_ to do it. And at second: Chess games and boards are typeset with commands so it doesn't matter much where a glyph is in a font as long as all chess fonts use the same standard so that you can switch fonts without problems. The standard used by chessfss is (for historical reasons) the font chart of the skak/skaknew fonts. -- Ulrike Fischer
On 28-10-2010 10:34, Ulrike Fischer wrote:
Even if unicode would have a code point for every symbol: At first my problem is not _where_ to map a glyph but _how_ to do it. And at second: Chess games and boards are typeset with commands so it doesn't matter much where a glyph is in a font as long as all chess fonts use the same standard so that you can switch fonts without problems. The standard used by chessfss is (for historical reasons) the font chart of the skak/skaknew fonts.
\directlua{fonts.otf.char("glyphname")} Should work. ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am Thu, 28 Oct 2010 14:33:03 +0200 schrieb Hans Hagen:
On 28-10-2010 10:34, Ulrike Fischer wrote:
Even if unicode would have a code point for every symbol: At first my problem is not _where_ to map a glyph but _how_ to do it. And at second: Chess games and boards are typeset with commands so it doesn't matter much where a glyph is in a font as long as all chess fonts use the same standard so that you can switch fonts without problems. The standard used by chessfss is (for historical reasons) the font chart of the skak/skaknew fonts.
\directlua{fonts.otf.char("glyphname")}
Should work.
No, it doesn't work. \directlua{fonts.otf.char("c140")} doesn't give the King ("c140", \char140) but an "aring" due to the entry unicodes={...,c140={ 229, 140 },...} in temp-pirat.lua generated by luaoftload. \documentclass{article} \usepackage{luaotfload} \pagestyle{empty} \begin{document} \font\test={name:Chess Figurine Pirat} \test \char140 \directlua{fonts.otf.char("c140")} \end{document} So how can I change the fontdata so that \directlua{fonts.otf.char("c140")} gives the correct glyph? And when I have corrected the fontdata, is there a way (besides using a fea-file) to manipulate the fontdata so that the input "K" outputs the glyph "c140"? -- Ulrike Fischer
On 10/28/2010 02:57 PM, Ulrike Fischer wrote:
And when I have corrected the fontdata, is there a way (besides using a fea-file) to manipulate the fontdata so that the input "K" outputs the glyph "c140"?
I have not followed this closely, bit it seems to me that the problem is more likely caused by a fea file than that it is cured by it.
Am Thu, 28 Oct 2010 15:08:09 +0200 schrieb Taco Hoekwater:
And when I have corrected the fontdata, is there a way (besides using a fea-file) to manipulate the fontdata so that the input "K" outputs the glyph "c140"?
I have not followed this closely, bit it seems to me that the problem is more likely caused by a fea file than that it is cured by it.
The problem is that I have some highly non-standard (mostly ttf-)fonts with glyphs with non-standard names ordered in non-standard ways. The problem exists without using fea-files at all! I will ask the other way round: If you have a font loaded with e.g. \font\test={name:Arial) in context. Can you manipulate the fontdata so that when you use this font ABC outputs the glyphs CDE? If yes how do you do it? If no: can I define a virtual font which does the task? I naturally don't want to disturb the font loading system of luaotfload. Or to write a font loader. I don't have enough knowledge to do this. -- Ulrike Fischer
On Thu, Oct 28, 2010 at 03:08:09PM +0200, Taco Hoekwater wrote:
On 10/28/2010 02:57 PM, Ulrike Fischer wrote:
And when I have corrected the fontdata, is there a way (besides using a fea-file) to manipulate the fontdata so that the input "K" outputs the glyph "c140"?
I have not followed this closely, bit it seems to me that the problem is more likely caused by a fea file than that it is cured by it.
It seems like the font is using that multiple code points for the same glyph some thing of TrueType, I'm not sure, but I recall FF documentation recommending against using it. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
On 28-10-2010 3:33, Khaled Hosny wrote:
On Thu, Oct 28, 2010 at 03:08:09PM +0200, Taco Hoekwater wrote:
On 10/28/2010 02:57 PM, Ulrike Fischer wrote:
And when I have corrected the fontdata, is there a way (besides using a fea-file) to manipulate the fontdata so that the input "K" outputs the glyph "c140"?
I have not followed this closely, bit it seems to me that the problem is more likely caused by a fea file than that it is cured by it.
It seems like the font is using that multiple code points for the same glyph some thing of TrueType, I'm not sure, but I recall FF documentation recommending against using it.
indeed there is some multiple mapping going on and as we're dealing with sparse tables and loops over a hash we get a bit arbitrary matches when there are multiple ... there is also some pretty high altuni field present if I look at the font in fontforge the chess symbols sit in latin slots so it's in the font if the font is okay, accessing by glyph name will work ok Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am Thu, 28 Oct 2010 16:59:34 +0200 schrieb Hans Hagen:
And when I have corrected the fontdata, is there a way (besides using a fea-file) to manipulate the fontdata so that the input "K" outputs the glyph "c140"?
I have not followed this closely, bit it seems to me that the problem is more likely caused by a fea file than that it is cured by it.
It seems like the font is using that multiple code points for the same glyph some thing of TrueType, I'm not sure, but I recall FF documentation recommending against using it.
indeed there is some multiple mapping going on and as we're dealing with sparse tables and loops over a hash we get a bit arbitrary matches when there are multiple ...
there is also some pretty high altuni field present
if I look at the font in fontforge the chess symbols sit in latin slots so it's in the font
Yes, I know that the font is a bit dubious. That's the case for quite a lot of the free chessfonts. The question I have: How can I correct the fontdata after I have loaded the font? -- Ulrike Fischer
On 28-10-2010 5:37, Ulrike Fischer wrote:
The question I have: How can I correct the fontdata after I have loaded the font?
in context it is possible to 'patch' a font before it gets cached but that's just a hack; in luaotf I can imagine that you intercept the font just before it gets passed to tex, but anyway, it's asking for problems with respect to future proof processing Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am Thu, 28 Oct 2010 18:01:07 +0200 schrieb Hans Hagen:
The question I have: How can I correct the fontdata after I have loaded the font?
in context it is possible to 'patch' a font before it gets cached but that's just a hack; in luaotf I can imagine that you intercept the font just before it gets passed to tex, but anyway, it's asking for problems with respect to future proof processing
Well I don't want to patch the font system. But why can't I change the font data after the \font\test=... line? Is the data somewhere in the memory where it can't be touched? If yes is it possible to copy the data, change it and then use the changed data to define a new font \testb? -- Ulrike Fischer
On 28-10-2010 7:08, Ulrike Fischer wrote:
Am Thu, 28 Oct 2010 18:01:07 +0200 schrieb Hans Hagen:
The question I have: How can I correct the fontdata after I have loaded the font?
in context it is possible to 'patch' a font before it gets cached but that's just a hack; in luaotf I can imagine that you intercept the font just before it gets passed to tex, but anyway, it's asking for problems with respect to future proof processing
Well I don't want to patch the font system. But why can't I change the font data after the \font\test=... line? Is the data somewhere in the memory where it can't be touched? If yes is it possible to copy the data, change it and then use the changed data to define a new font \testb?
as direct manipulation at that level is doomed to fail in the future (nothing is written in stone till we have luatex 1.0) the best I can think of is to provide a function that does the job i.e. stupify the mapping, something fonts.otf.simplifynamemapping or so, or better provide that as feature so that one can enable it; really this is the only robust way Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am Thu, 28 Oct 2010 19:17:19 +0200 schrieb Hans Hagen:
The question I have: How can I correct the fontdata after I have loaded the font?
in context it is possible to 'patch' a font before it gets cached but that's just a hack; in luaotf I can imagine that you intercept the font just before it gets passed to tex, but anyway, it's asking for problems with respect to future proof processing
Well I don't want to patch the font system. But why can't I change the font data after the \font\test=... line? Is the data somewhere in the memory where it can't be touched? If yes is it possible to copy the data, change it and then use the changed data to define a new font \testb?
as direct manipulation at that level is doomed to fail in the future (nothing is written in stone till we have luatex 1.0) the best I can think of is to provide a function that does the job
Hm. I do have a bit the impression as if we have here a context and latex philosophy clash. I'm not asking you to provide a funktion incorporated in the context code which does the job. _I_ want to write support files for the chess ttf-fonts. If I get something working I will perhaps add it to my package. And if something changes in luatex or the underlying luaotfload/context code, well then I will have to adjust my code. Couldn't you give some examples how to manipulate a font after it has been defined with \font\test (if it is possible) and then let me play around? -- Ulrike Fischer
On 28-10-2010 7:48, Ulrike Fischer wrote:
Hm. I do have a bit the impression as if we have here a context and latex philosophy clash. I'm not asking you to provide a funktion
Huh? I'm not sure what philosophy refers to, as I'm not refering to context but to the otf loading code; so it would be a function in the lua code base (it would not even be interfaced to context as it would invalidate most of the characters in a font).
incorporated in the context code which does the job. _I_ want to write support files for the chess ttf-fonts. If I get something working I will perhaps add it to my package. And if something changes in luatex or the underlying luaotfload/context code, well then I will have to adjust my code.
Sure, but the first complaints would end up in khaleds, tacos or my mailbox unless your package is private and never ends up in tex distributions). The fact that it's custom in latex to overload code and thus create a maintaince depency does not mean that I want such a dependency on my code. The context philosophy is to provide hooks and ignore all compliants about other usage cq. don't care about usage of code that is not meant to be accesses directly. (Also, Khaled then provides the interface to the latex packages.)
Couldn't you give some examples how to manipulate a font after it has been defined with \font\test (if it is possible) and then let me play around?
I have no clue about the lualatex interface i.e. at what point you can hook in code. Keep in mind that messing around with a font before or during loading can influence other instances of that font as some data is shared. Also, once the font lives at the tex end, some data is frozen. Because some of the font's metadata is used in otf processing one cannot change that data without keeping that in mind. Anyhow, you can access some font data afterwards. In context form: \startluacode function Whatever(name) for k, v in pairs(fonts.ids[font.current()].descriptions) do if v.name == name then tex.sprint("\\char"..k.."\\relax") break end end end \stopluacode \font\test=file:pirat.ttf \def\MyChessChar#1{{\test\directlua{Whatever("#1")}}} \MyChessChar{c160} This is dead slow and inefficient but as you don't want a proper function for it I don't care too much. Interesting is that it does not work out (as wis to be expected as the normal glyph access function does something similar). Btw, a bit of testing at my end shows that there is something fishy with the font with respect to inclusion in the pdf so it can well be that the accessor is ok and something else is the problem. As taco mentioned in an earlier mail, we will look into it (even it makes not much sense). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am Thu, 28 Oct 2010 20:56:41 +0200 schrieb Hans Hagen:
Hm. I do have a bit the impression as if we have here a context and latex philosophy clash. I'm not asking you to provide a funktion
Huh? I'm not sure what philosophy refers to,
Well I refer to sentences like this:
Sure, but the first complaints would end up in ... my mailbox unless your package is private ....
The fact that it's custom in latex to overload code and thus create a maintaince depency does not mean that I want such a dependency on my code.
Unlike context latex is decentral. Reponsability is splitted. And so no one would feel that I'm a thread for "their" code or to their support burden if I would announce a package. Nobody would feel the urge to take away the task from me for fear that I break something. Anyway: I'm writing latex packages. Whatever I will do: no context user will be affected by my code.
Couldn't you give some examples how to manipulate a font after it has been defined with \font\test (if it is possible) and then let me play around?
...
Anyhow, you can access some font data afterwards. In context form:
\startluacode function Whatever(name) for k, v in pairs(fonts.ids[font.current()].descriptions) do if v.name == name then tex.sprint("\\char"..k.."\\relax") break end end end \stopluacode \font\test=file:pirat.ttf \def\MyChessChar#1{{\test\directlua{Whatever("#1")}}} \MyChessChar{c160}
This is dead slow and inefficient but as you don't want a proper function for it I don't care too much.
This is an interesting piece of code but not actually what I asked for. I don't need to loop through the font to find out the correct \char-command connected to a glyph. I can look it up in fontforge and store it in a table. I need a way to reencode/reorder the font, so that the input "K" points to the glyph "c140". Pirat is not the only chessfont I have, I don't want to change the input if I change the font, so every chessfont should have the same internal order. My main problem is that they are so few informations about the generic context font loader code. E.g. after the rereading of the luatex manual I came up with the following: \starttext \font\test={file:PIRAT.TTF} \test %K\char75\char140\char140 \directlua{ mytable=font.fonts[font.id('test')] mytable.characters[75],mytable.characters[140]=mytable.characters[140],mytable.characters[75] tex.definefont("testb",font.define(mytable)) } \testb K\char75\char140\char140 \stoptext Then input "K" gives me (as wanted) a king. But it leads to questions: 1. Why is the spacing in \testb wrong if the chars have been already used after \test? 2. Which values/tables in mytable should I reset/change too to get a "sane" font \testb? 3. I can also use "mytable=fonts.ids[font.id('test')]". Is this better? What are the differences?
Interesting is that it does not work out (as wis to be expected as the normal glyph access function does something similar).
? I didn't understand this remark. If you mean that you didn't get an output: There is nothing at position 160. The king is c140. -- Ulrike Fischer
On 2-11-2010 4:16, Ulrike Fischer wrote:
and store it in a table. I need a way to reencode/reorder the font, so that the input "K" points to the glyph "c140". Pirat is not the only chessfont I have, I don't want to change the input if I change the font, so every chessfont should have the same internal order.
(1) you can write your own fontloader (which in the case of a symbol font is no big deal, i.e. just slots and dimensions and 1-to-1 mapping as no unicode is needed, and info about that can be found in the luatex manual) (2) you can intercept the table just before it is passed to tex (for which you need to look into the bit of code that latex i.e. just before font.define is called and the table passed is the one that needs to be tweaked, that table conforms to the luatex spec)
My main problem is that they are so few informations about the generic context font loader code. E.g. after the rereading of the luatex manual I came up with the following:
(3) some day I'll probably document the relevant (and public) part of the low level interface; till then the source is the documentation (probably of not much use outside context as we have a different font model)
1. Why is the spacing in \testb wrong if the chars have been already used after \test?
because the font is already loaded and frozen
2. Which values/tables in mytable should I reset/change too to get a "sane" font \testb?
whatever value you want, but before the font is passed to tex (so before font.define is called cq. the font define callback is finished in the latex code)
3. I can also use "mytable=fonts.ids[font.id('test')]". Is this better? What are the differences?
fonts.ids accessed the font info that lives at the tex end but changing values like widths won't have any effect on tex as they are frozen already (after all they end up in backend code as well) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hi Khaled, In a next version of the oft code I do a bit more strict encoding test; not that it matters much but we need to keen an eye on fonts that have multiple code points mapped onto the same glyph. It does not solve the chess problem (something taco and I will look into tomorrow). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Thu, Oct 28, 2010 at 09:35:08PM +0200, Hans Hagen wrote:
Hi Khaled,
In a next version of the oft code I do a bit more strict encoding test; not that it matters much but we need to keen an eye on fonts that have multiple code points mapped onto the same glyph.
I'm syncing luaotfload with latest context code and many of my tests are broken, I think I'll wait for the next update to do another sync before debugging (for some reason node mode ceased to work). Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
On 28-10-2010 9:46, Khaled Hosny wrote:
On Thu, Oct 28, 2010 at 09:35:08PM +0200, Hans Hagen wrote:
Hi Khaled,
In a next version of the oft code I do a bit more strict encoding test; not that it matters much but we need to keen an eye on fonts that have multiple code points mapped onto the same glyph.
I'm syncing luaotfload with latest context code and many of my tests are broken, I think I'll wait for the next update to do another sync before debugging (for some reason node mode ceased to work).
I'm in the process of cleaning up some code so that could interfere with your end, although I didn't change much in that code, normally I keep an eye on the generic code. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 10/28/2010 04:59 PM, Hans Hagen wrote:
if the font is okay, accessing by glyph name will work ok
The font is an 8-bit encoding-indexed Macintosh Roman font presenting itself as TrueType, and that is why it is so confusing. Because the font says it is in MacRoman encoding, and the glyph names are pointless affairs like /c140 (which is the king symbol) instead of sane names, fontforge takes that the '140' part of the name is a decimal code point in MacRoman encoding. This is correct behavior on fontforge's part, but it means that the Unicode remap becomes slightly messy, as /c140 maps to 'LATIN SMALL LETTER A WITH RING ABOVE'., and the glyph named /c229 (which is in fact the aring symbol) maps to 'LATIN CAPITAL A WITH CIRCUMFLEX', and /194 (which is the Acirc) maps to 'NOT SIGN', etc. etc. In short: the font's glyph naming is anemic. Now, it appears that luaotfload produces a rubbish .lua file, probably because it dumps both the MacRoman and the Unicode assignment at the same time as a merged table. That is a bug, but that is an issue for the luaotfload maintainers, not something for the context mailing list. In context itself, \char140 actually and correctly produces the king symbol. Incidentally, in context, you can get a dump of the actually used unicode slots by running: \starttext \showfont[PIRAT.TTF][all] % grid table \stoptext or \usemodule[fnt-10] \starttext \ShowCompleteFont{PIRAT.TTF}{12pt}{1} % number&names table \stoptext Now, about fixing it: I don't think there is much you can do with a feature file in this case. If you want to make glyph (name) changes, it is better to do so in the actual font file, because the fea file will get hopelessly confusing. (and it will be specific to this particular font file anyway), and more importantly: if you use a fea file, you will keep hitting that luaotfload bug. So either clean up the font yourself, or report a luaotfload bug and wait for it to be fixed ... Best wishes, Taco
On Thu, Oct 28, 2010 at 05:48:12PM +0200, Taco Hoekwater wrote:
On 10/28/2010 04:59 PM, Hans Hagen wrote:
if the font is okay, accessing by glyph name will work ok
The font is an 8-bit encoding-indexed Macintosh Roman font presenting itself as TrueType, and that is why it is so confusing.
Because the font says it is in MacRoman encoding, and the glyph names are pointless affairs like /c140 (which is the king symbol) instead of sane names, fontforge takes that the '140' part of the name is a decimal code point in MacRoman encoding.
This is correct behavior on fontforge's part, but it means that the Unicode remap becomes slightly messy, as /c140 maps to 'LATIN SMALL LETTER A WITH RING ABOVE'., and the glyph named /c229 (which is in fact the aring symbol) maps to 'LATIN CAPITAL A WITH CIRCUMFLEX', and /194 (which is the Acirc) maps to 'NOT SIGN', etc. etc. In short: the font's glyph naming is anemic.
Now, it appears that luaotfload produces a rubbish .lua file, probably because it dumps both the MacRoman and the Unicode assignment at the same time as a merged table. That is a bug, but that is an issue for the luaotfload maintainers, not something for the context mailing list.
As one of the luaotfload maintainers, I assure you that we never touch such low level code :) at least to stay compatible with ConTeXt (I really really have no interest in two incompatible OpenType implementations, so in regard to that luaotfload is not a real fork but ConTeXt code wrapped in some LaTeX palatable sweetener).
In context itself, \char140 actually and correctly produces the king symbol.
This either means it was fixed in later version of ConTeXt (our code is derived from the texlive version), or the ConTeXt variant is doing more stuff than what the plain one does. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
On 28-10-2010 5:59, Khaled Hosny wrote:
As one of the luaotfload maintainers, I assure you that we never touch such low level code :) at least to stay compatible with ConTeXt (I really really have no interest in two incompatible OpenType implementations, so in regard to that luaotfload is not a real fork but ConTeXt code wrapped in some LaTeX palatable sweetener).
in that case it's fontforge that merges the two vectors (technically we can have one glyph name representing two unicode points) using the /C<num> logic that taco mentions; the best solution is to have sane glyph names
This either means it was fixed in later version of ConTeXt (our code is derived from the texlive version), or the ConTeXt variant is doing more stuff than what the plain one does.
it also relates to looping over the sparse tables ... sort of arbitrary what comes first but, as taco mentions, \char140 does give a king here; doesn't it in latex? ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 28-10-2010 5:59, Khaled Hosny wrote:
This either means it was fixed in later version of ConTeXt (our code is derived from the texlive version), or the ConTeXt variant is doing more stuff than what the plain one does.
probably the only way out of this font mess is to have extra hash table (could be a feature like : namehash=yes) although it obscures the fact that there is a problem in the font which a few years from now makes debugging user problems a pain as no one is going to remember this Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am Thu, 28 Oct 2010 17:48:12 +0200 schrieb Taco Hoekwater:
Now, it appears that luaotfload produces a rubbish .lua file, probably because it dumps both the MacRoman and the Unicode assignment at the same time as a merged table. That is a bug, but that is an issue for the luaotfload maintainers, not something for the context mailing list.
In context itself, \char140 actually and correctly produces the king symbol.
Well miktex has again a working context.
ConTeXt ver: 2010.05.24 13:05 MKIV fmt: 2010.10.28 int:
english/english
So I tried the following example (I had to copy the font in document
folder, context didn't find it in the system folder):
\starttext
hello
\font\test={file:PIRAT.TTF}
\test
\char140 \directlua{fonts.otf.char("c140")}
\stoptext
This example gave exactly the same output as the comparable latex
example with luaotfload: \char140 gives the king, the
\directlua-command gives the aring.
I also compared the font files generated by both systems:
temp-pirat.lua from luaotfload and pirat.tma from context. Both are
nearly identical. They differ only in some boundingbox settings,
versions and a kern setting. Both contain in the unicodes table the
setting c140={ 229, 140 }.
I changed this setting in pirat.tma to c140=140 and deletec
pirat.tmc and recompiled my document: Now
\directlua{fonts.otf.char("c140")} gave as wanted the king.
So please tell me how can I make the change in my document. What
code should I insert here:
\starttext
\font\test={file:PIRAT.TTF}
Ulrike Fischer wrote:
This example gave exactly the same output as the comparable latex example with luaotfload: \char140 gives the king, the \directlua-command gives the aring.
My apologies to Khaled Hosny, I was wrong. It is still a bug though, that '140' has no business being in the unicodes table. Hans and I will do some further debugging. Best wishes, Taco
On Thu, Oct 28, 2010 at 07:03:14PM +0200, taco wrote:
Ulrike Fischer wrote:
This example gave exactly the same output as the comparable latex example with luaotfload: \char140 gives the king, the \directlua-command gives the aring.
My apologies to Khaled Hosny, I was wrong.
No need for apology (if it were my fault life would have been easier, now I have to sync with context which is tricky since lots of things changed since my last sync). Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer
On 28-10-2010 2:57, Ulrike Fischer wrote:
Am Thu, 28 Oct 2010 14:33:03 +0200 schrieb Hans Hagen:
On 28-10-2010 10:34, Ulrike Fischer wrote:
Even if unicode would have a code point for every symbol: At first my problem is not _where_ to map a glyph but _how_ to do it. And at second: Chess games and boards are typeset with commands so it doesn't matter much where a glyph is in a font as long as all chess fonts use the same standard so that you can switch fonts without problems. The standard used by chessfss is (for historical reasons) the font chart of the skak/skaknew fonts.
\directlua{fonts.otf.char("glyphname")}
Should work.
No, it doesn't work.
\directlua{fonts.otf.char("c140")} doesn't give the King ("c140", \char140) but an "aring" due to the entry
unicodes={...,c140={ 229, 140 },...}
in temp-pirat.lua generated by luaoftload.
\documentclass{article} \usepackage{luaotfload} \pagestyle{empty} \begin{document} \font\test={name:Chess Figurine Pirat} \test \char140 \directlua{fonts.otf.char("c140")} \end{document}
So how can I change the fontdata so that \directlua{fonts.otf.char("c140")} gives the correct glyph?
And when I have corrected the fontdata, is there a way (besides using a fea-file) to manipulate the fontdata so that the input "K" outputs the glyph "c140"?
I can't speak for latex so if you want an answer then I need the font in order to see what happens in context as that is the reference. ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am Thu, 28 Oct 2010 15:10:20 +0200 schrieb Hans Hagen:
I can't speak for latex so if you want an answer then I need the font in order to see what happens in context as that is the reference.
The font is here: http://www.enpassant.dk/chess/downl/pirat.zip (I'm not expecting context or luaotfload to handle such a non-standard font automatically. I'm only trying to find out how to write the code needed to adjust the font.) -- Ulrike Fischer
participants (6)
-
Aditya Mahajan -
Hans Hagen -
Khaled Hosny -
taco -
Taco Hoekwater
-
Ulrike Fischer