You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(7) |
Nov
|
Dec
(1) |
2004 |
Jan
|
Feb
(3) |
Mar
|
Apr
(8) |
May
(7) |
Jun
|
Jul
|
Aug
(3) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(10) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(11) |
Oct
(2) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
(5) |
Mar
(6) |
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
(7) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(20) |
Jul
(46) |
Aug
(19) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(5) |
Dec
|
2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(7) |
Jul
(2) |
Aug
(8) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
From: <ek...@di...> - 2020-12-31 05:53:51
|
I ended up making a small python script to generate all the substitutions Dec 27, 2020 10:01:40 PM Martin Hosken <mar...@si...>: > Dear ekaunt, > >> Suppose I had two classes >> >> uppercase = codepoint("ABCDEFGHIJKLMNOPQRSTUVWXYZ"); >> lowercase = codepoint("abcdefghijklmnopqrstuvwxyz"); >> >> and I wanted to convert every uppercase letter to a "S" if it's preceded by the corresponding lowercase letter (so "bB" becomes "bS", "fF" becomes "fS", but "cD" stays as "cD"), how would I do that? >> >> Doing `lowercase uppercase > @1 U+0053` doesn't work because then any combination of lowercase and uppercase becomes lowercase + S including "cD" becoming "cS" (and I only want the corresponding uppercase to match) >> >> Doing `uppercase > U+0053 / lowercase _;` doesn't work either for the same reason. >> >> I can't figure it out. Can anyone please help me out? > > The matching part of Graphite's rules is not dynamic. Thus it is based purely on static glyph strings. This means there is no way to use the index into one class when matching another. In other words, unless someone is more sneaky, you are going to have to flatten the whole thing out: > > ga > g_s / g_a _; > gb > g_s / g_b _; > gc > g_s / g_c _; > > etc. > > This is tedious but is no less efficient than what the compiler would end up producing, anyway, with any more sophisticated way of writing the rules. If you want to save a bit of effort you could do something like: > > #define myrule(x) g ## x > g_S / g_ ## x _ > > myrule(a); > myrule(b); > myrule(c); > > Or you can write code to generate a .gdl file that you then #include. > > HTH, > Yours, > Martin > |
From: Martin H. <mar...@si...> - 2020-12-28 03:26:57
|
Dear ekaunt, > Suppose I had two classes > > uppercase = codepoint("ABCDEFGHIJKLMNOPQRSTUVWXYZ"); > lowercase = codepoint("abcdefghijklmnopqrstuvwxyz"); > > and I wanted to convert every uppercase letter to a "S" if it's preceded by the corresponding lowercase letter (so "bB" becomes "bS", "fF" becomes "fS", but "cD" stays as "cD"), how would I do that? > > Doing `lowercase uppercase > @1 U+0053` doesn't work because then any combination of lowercase and uppercase becomes lowercase + S including "cD" becoming "cS" (and I only want the corresponding uppercase to match) > > Doing `uppercase > U+0053 / lowercase _;` doesn't work either for the same reason. > > I can't figure it out. Can anyone please help me out? The matching part of Graphite's rules is not dynamic. Thus it is based purely on static glyph strings. This means there is no way to use the index into one class when matching another. In other words, unless someone is more sneaky, you are going to have to flatten the whole thing out: ga > g_s / g_a _; gb > g_s / g_b _; gc > g_s / g_c _; etc. This is tedious but is no less efficient than what the compiler would end up producing, anyway, with any more sophisticated way of writing the rules. If you want to save a bit of effort you could do something like: #define myrule(x) g ## x > g_S / g_ ## x _ myrule(a); myrule(b); myrule(c); Or you can write code to generate a .gdl file that you then #include. HTH, Yours, Martin |
From: <ek...@di...> - 2020-12-27 02:38:33
|
Suppose I had two classes uppercase = codepoint("ABCDEFGHIJKLMNOPQRSTUVWXYZ"); lowercase = codepoint("abcdefghijklmnopqrstuvwxyz"); and I wanted to convert every uppercase letter to a "S" if it's preceded by the corresponding lowercase letter (so "bB" becomes "bS", "fF" becomes "fS", but "cD" stays as "cD"), how would I do that? Doing `lowercase uppercase > @1 U+0053` doesn't work because then any combination of lowercase and uppercase becomes lowercase + S including "cD" becoming "cS" (and I only want the corresponding uppercase to match) Doing `uppercase > U+0053 / lowercase _;` doesn't work either for the same reason. I can't figure it out. Can anyone please help me out? |
From: BPJ <bp...@me...> - 2015-08-11 16:54:26
|
Den 2015-08-11 16:24, Sharon Correll skrev: > Yes, you can certainly use underscores and digits in class and attribute names. > It looks like they can't start with these, though. > > Personally I don't like underscores as much in GDL because they get confused > with the underscores in rules, which have specific meanings. But it is up to you. I'm used to making a distinction between underscore surrounded by whitespace and not so surrounded, so I don't perceive as big a problem with that as with parsing lots of low-redundancy camelcase words while scanning code. I guess variable names based on English words make the latter worse for me as a non-native speaker. > > > On 8/11/2015 6:24 AM, BPJ wrote: >> Hi, >> >> What are the valid characters and syntax of identifiers (classes >> etc.)? Most examples use CamelCase but I noticed one example in >> the tutorial mateial which uses underscored_words, which I much >> prefer. OTOH I nowhere see examples of identifiers with digits. >> What gives? >> >> /bpj >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Silgraphite-fonts mailing list >> Sil...@li... >> https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Silgraphite-fonts mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts > |
From: BPJ <bp...@me...> - 2015-08-11 16:31:38
|
Den 2015-08-11 15:31, Jim Brase skrev: > I haven't used Illustrator, but I did a quick experiment with Acrobat. > I'm using Windows 8.1, Acrobat Pro XI, XeTex, Tai Dam language text in > the Tai Viet script, and the Tai Heritage Pro font. I opened the XeTex > output in Acrobat. I was able to add/remove pages, highlight text, and > edit Latin text. > > When I tried to edit Tai Viet text, it became a bit problematic: My > Keyman keyboard did not seem to function inside of Acrobat. I was able > to paste Tai Viet characters into the text from the clipboard, but the > Graphite rendering did not work. That is not surprising. However, I > would never edit XeTex output in this way--I would edit the source file > and rerun XeTex. So would I, but it has happened that my XeTeX-generated PDFs have been embedded in one way or another in Illustrator documents. I'll have to contact the people concerned and find out if they can embed a pdf as a 'black box', or if they are willing to conduct some experiments. As a last resort I'll have to instead/alternatively rely on solutions using TECkit. I was anyway expecting to largely have to rely on glyph substitution rather than positioning so it won't be an enormous difference, although I'll have to create or modify more glyphs, and I don't think everyone will be happy to have to use (Xe)LaTeX and/or plaintext rather than LibreOffice. For some reason some people, unlike me, like WYSIWYG! :-) Thank you for spending your time on this! /bpj > > Jim Brase > NRSI > > > On 8/11/2015 7:57 AM, BPJ wrote: >> Den 2015-08-11 13:42, Carsten Becker skrev: >>> Hi Benct, >>> >>> this should work in my experience, at least as far as Adobe Reader is >>> concerned. >> Hi Carsten, >> >> I'm using Ubuntu/GNOME and have had no problem *viewing such PDFs >> in a variety of viewers. >> I was thinking more of Illustrator and friends which actually open >> PDFs for editing. I should have pointed that out, but human >> beings are in the habit of taking things for granted! :-) >> >> /bpj >> >> >>> Here's a screenshot of my own Graphite-enabled font for my >>> own fictional alphabet (left; XeTeX) [1] and another document set in >>> Linux Libertine G, which uses Graphite for typographic ligatures (Th, >>> fi, ff et al.) among others (right; LibreOffice 4) [2]. The fonts are >>> partially embedded in the PDF files in both cases according to the file >>> properties dialog. >>> >>> <http://i.imgur.com/drMYXph.png> >>> >>> I'm viewing this in Adobe Reader 11.0.08 running with WINE 1.7.44 on >>> KUbuntu 15.04. >>> >>> Regards >>> Carsten >>> >>> [1] >>> <http://benung.nfshost.com/wp-content/uploads/2015/06/2015-06-29-lords-prayer.pdf> >>> [2] >>> <http://benung.nfshost.com/wp-content/uploads/2012/04/2012-04-07-imperial-messages.pdf> >>> >>> Am 11.08.2015 um 13:24 schrieb BPJ: >>> >>>> Can you open PDFs generated by Graphite-aware programs like XeTeX >>>> or LibreOffice in Adobe programs without losing the Graphite >>>> 'magic'? I ask because I don't have or use those programs, but >>>> some in my presumptive user base do, so the issue will certainly >>>> come up. >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Silgraphite-fonts mailing list >>> Sil...@li... >>> https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Silgraphite-fonts mailing list >> Sil...@li... >> https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts > > > ------------------------------------------------------------------------------ > _______________________________________________ > Silgraphite-fonts mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts > |
From: Sharon C. <sha...@si...> - 2015-08-11 14:24:19
|
<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Yes, you can certainly use underscores and digits in class and attribute names. It looks like they can't start with these, though.<br> <br> Personally I don't like underscores as much in GDL because they get confused with the underscores in rules, which have specific meanings. But it is up to you.<br> <br> <br> <div class="moz-cite-prefix">On 8/11/2015 6:24 AM, BPJ wrote:<br> </div> <blockquote cite="mid:55C...@me..." type="cite"> <pre wrap="">Hi, What are the valid characters and syntax of identifiers (classes etc.)? Most examples use CamelCase but I noticed one example in the tutorial mateial which uses underscored_words, which I much prefer. OTOH I nowhere see examples of identifiers with digits. What gives? /bpj ------------------------------------------------------------------------------ _______________________________________________ Silgraphite-fonts mailing list <a class="moz-txt-link-abbreviated" href="mailto:Sil...@li...">Sil...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts">https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts</a> </pre> </blockquote> <br> </body> </html> |
From: Jim B. <jim...@si...> - 2015-08-11 13:57:37
|
I haven't used Illustrator, but I did a quick experiment with Acrobat. I'm using Windows 8.1, Acrobat Pro XI, XeTex, Tai Dam language text in the Tai Viet script, and the Tai Heritage Pro font. I opened the XeTex output in Acrobat. I was able to add/remove pages, highlight text, and edit Latin text. When I tried to edit Tai Viet text, it became a bit problematic: My Keyman keyboard did not seem to function inside of Acrobat. I was able to paste Tai Viet characters into the text from the clipboard, but the Graphite rendering did not work. That is not surprising. However, I would never edit XeTex output in this way--I would edit the source file and rerun XeTex. Jim Brase NRSI On 8/11/2015 7:57 AM, BPJ wrote: > Den 2015-08-11 13:42, Carsten Becker skrev: >> Hi Benct, >> >> this should work in my experience, at least as far as Adobe Reader is >> concerned. > Hi Carsten, > > I'm using Ubuntu/GNOME and have had no problem *viewing such PDFs > in a variety of viewers. > I was thinking more of Illustrator and friends which actually open > PDFs for editing. I should have pointed that out, but human > beings are in the habit of taking things for granted! :-) > > /bpj > > >> Here's a screenshot of my own Graphite-enabled font for my >> own fictional alphabet (left; XeTeX) [1] and another document set in >> Linux Libertine G, which uses Graphite for typographic ligatures (Th, >> fi, ff et al.) among others (right; LibreOffice 4) [2]. The fonts are >> partially embedded in the PDF files in both cases according to the file >> properties dialog. >> >> <http://i.imgur.com/drMYXph.png> >> >> I'm viewing this in Adobe Reader 11.0.08 running with WINE 1.7.44 on >> KUbuntu 15.04. >> >> Regards >> Carsten >> >> [1] >> <http://benung.nfshost.com/wp-content/uploads/2015/06/2015-06-29-lords-prayer.pdf> >> [2] >> <http://benung.nfshost.com/wp-content/uploads/2012/04/2012-04-07-imperial-messages.pdf> >> >> Am 11.08.2015 um 13:24 schrieb BPJ: >> >>> Can you open PDFs generated by Graphite-aware programs like XeTeX >>> or LibreOffice in Adobe programs without losing the Graphite >>> 'magic'? I ask because I don't have or use those programs, but >>> some in my presumptive user base do, so the issue will certainly >>> come up. >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Silgraphite-fonts mailing list >> Sil...@li... >> https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Silgraphite-fonts mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts |
From: BPJ <bp...@me...> - 2015-08-11 11:57:31
|
Den 2015-08-11 13:42, Carsten Becker skrev: > Hi Benct, > > this should work in my experience, at least as far as Adobe Reader is > concerned. Hi Carsten, I'm using Ubuntu/GNOME and have had no problem *viewing such PDFs in a variety of viewers. I was thinking more of Illustrator and friends which actually open PDFs for editing. I should have pointed that out, but human beings are in the habit of taking things for granted! :-) /bpj > Here's a screenshot of my own Graphite-enabled font for my > own fictional alphabet (left; XeTeX) [1] and another document set in > Linux Libertine G, which uses Graphite for typographic ligatures (Th, > fi, ff et al.) among others (right; LibreOffice 4) [2]. The fonts are > partially embedded in the PDF files in both cases according to the file > properties dialog. > > <http://i.imgur.com/drMYXph.png> > > I'm viewing this in Adobe Reader 11.0.08 running with WINE 1.7.44 on > KUbuntu 15.04. > > Regards > Carsten > > [1] > <http://benung.nfshost.com/wp-content/uploads/2015/06/2015-06-29-lords-prayer.pdf> > [2] > <http://benung.nfshost.com/wp-content/uploads/2012/04/2012-04-07-imperial-messages.pdf> > > Am 11.08.2015 um 13:24 schrieb BPJ: > >> Can you open PDFs generated by Graphite-aware programs like XeTeX >> or LibreOffice in Adobe programs without losing the Graphite >> 'magic'? I ask because I don't have or use those programs, but >> some in my presumptive user base do, so the issue will certainly >> come up. > > ------------------------------------------------------------------------------ > _______________________________________________ > Silgraphite-fonts mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts > |
From: Carsten B. <ca...@gm...> - 2015-08-11 11:42:19
|
Hi Benct, this should work in my experience, at least as far as Adobe Reader is concerned. Here's a screenshot of my own Graphite-enabled font for my own fictional alphabet (left; XeTeX) [1] and another document set in Linux Libertine G, which uses Graphite for typographic ligatures (Th, fi, ff et al.) among others (right; LibreOffice 4) [2]. The fonts are partially embedded in the PDF files in both cases according to the file properties dialog. <http://i.imgur.com/drMYXph.png> I'm viewing this in Adobe Reader 11.0.08 running with WINE 1.7.44 on KUbuntu 15.04. Regards Carsten [1] <http://benung.nfshost.com/wp-content/uploads/2015/06/2015-06-29-lords-prayer.pdf> [2] <http://benung.nfshost.com/wp-content/uploads/2012/04/2012-04-07-imperial-messages.pdf> Am 11.08.2015 um 13:24 schrieb BPJ: > Can you open PDFs generated by Graphite-aware programs like XeTeX > or LibreOffice in Adobe programs without losing the Graphite > 'magic'? I ask because I don't have or use those programs, but > some in my presumptive user base do, so the issue will certainly > come up. |
From: BPJ <bp...@me...> - 2015-08-11 11:25:00
|
Hi, What are the valid characters and syntax of identifiers (classes etc.)? Most examples use CamelCase but I noticed one example in the tutorial mateial which uses underscored_words, which I much prefer. OTOH I nowhere see examples of identifiers with digits. What gives? /bpj |
From: BPJ <bp...@me...> - 2015-08-11 11:24:31
|
Hi, Can you open PDFs generated by Graphite-aware programs like XeTeX or LibreOffice in Adobe programs without losing the Graphite 'magic'? I ask because I don't have or use those programs, but some in my presumptive user base do, so the issue will certainly come up. /bpj |
From: Martin H. <mar...@si...> - 2015-07-28 03:28:02
|
On Mon, 27 Jul 2015 20:39:19 +0200 BPJ <bp...@me...> wrote: > I tried Graphite and GDL some years ago and am now revisiting. I > have two questions which I hope are not easily found in the > documentation. :-) > > 1. How do you express an end-of-word environment? This is best handled by a negative rule. We don't try to match end-of-word, we instead match not end-of-word and do nothing, and then make a no contextual rule that catches the other case (end-of-word). Why do we do that? Because currently we don't support line end contextuals or string end contextuals, and end-of-word includes end-of-string. First create a class of everything that you consider to be part of a word. This isn't so bad since word-break lists include quite a few characters. Then create two rules. One rule matches against the in word environment and does nothing, the other more generic (and so shorter and lower priority) rule will fire if the environment is end of word. E.g. for say Greek final sigma, in cFinal and cIsolate containing normal sigma. cIsolate > @1 / _ ^ cWord; cIsolate > cFinal; although in this case for arabic you are more likely to do: cIsolate > cFinal / cWord ^ _; cIsolate > cInit / _ ^ cWord; cFinal > cMedial / _ ^ cWord; or something like that. But that's answering a different question ;) If you need help crafting your particular rule, I'm happy to help. > 2. How do you remove all instances of a glyph (context free). That's a good question because the obvious answer is not the right answer, unfortunately: cDel > _; has an unfortunate effect of doing strange things with the cursor, since the engine doesn't know whether you want the deleted character to be associated with the following or previous glyph. A better solution is: cDel ANY > _ @2:(1 2); this deletes the glyph and associates the character of the deleted glyph with the following glyph. If you want to associate the character with the previous glyph then use: ANY cDel > @1:(1 2} _; you may need to define ANY in table(glyph) using something like ANY = glyph(0 .. MAXGLYPH); where you #define MAXGLYPH to be the maximum glyphid in your font. make_gdl and graide will define it for you. > Thanks in advance, HTH. Followup questions are allowed :) Yours, Martin > > /bpj > > ------------------------------------------------------------------------------ > _______________________________________________ > Silgraphite-fonts mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts |
From: BPJ <bp...@me...> - 2015-07-27 19:23:07
|
I tried Graphite and GDL some years ago and am now revisiting. I have two questions which I hope are not easily found in the documentation. :-) 1. How do you express an end-of-word environment? 2. How do you remove all instances of a glyph (context free). Thanks in advance, /bpj |
From: Richard W. <ric...@nt...> - 2015-06-18 19:21:15
|
On Thu, 18 Jun 2015 08:52:43 +0700, Martin Hosken wrote: >> Is there a tool around that will convert the GSUB, GPOS and GDEF >> tables of an OpenType font to Graphite? > No there isn't. The main reason is that Graphite fonts tend to do > multiple things per pass, while OT fonts do lots of passes, at least > conceptually. That and integrating the shaper into the generated > Graphite means it's all a little tricky. Graphite fonts tend to take a > very different approach to describing the problem. OTOH you could well > be one of the people who could work it out! I've got to fit work round these activities! There's also the slight subtlety that GSUB isn't actually defined. The undocumented principle that marks on different components of a ligature don't interact seems to be implemented differently in HarfBuzz and Unicode/DirectWrite - my attempts to circumvent the rule have had varying degrees of success. A principled rendering of the Tai word for 'water' in Tai Tham has no end of problems. (For those not familiar with the word, it has two base characters, each with a mark. The base characters ligate, and the two marks swap round, as though the word were <ligature, mark on base 2, mark on base 1>.) > There are a couple of things going on here. > Did you see my email of > last week that suggested a different way of doing glyph attachment? Saw, but didn't study. > You may be using an older version of > make_gdl (if you are using it at all) that had a bug in this area. Last time I compiled I just used grCompiler V2.4 on handwritten code. (OK, I used a few macros.) I'm not familiar with make_gdl. I'm using my ugly font when I can because it'd easier to read so I haven't noticed the jumping about recently. Something seems to have gone wrong with the hinting or whatever in the Lannaworld-based graphite font. >> However, >> LibreOffice (via an extension, I believe) does seem to have support >> for Graphite features! > LibreOffice needs no extension to support Graphite fonts. You may be > thinking of an older extension that allows one to turn off the > Graphite support. I was thinking of the 'typography toolbar'. It turns out that it isn't necessary. > An alternative would be to allow the same feature setting syntax we > use in fonts, to work with the OT support in libreoffice. But that would > take some coding from someone. Yes, but I'm not keen on recommending that people compile LibreOffice for themselves. My last build took 4 hours, though of course adding a patch on top of a compiled build should be less painful. Richard. |
From: Martin H. <mar...@si...> - 2015-06-18 02:21:22
|
Dear Richard, > Is there a tool around that will convert the GSUB, GPOS and GDEF > tables of an OpenType font to Graphite? No there isn't. The main reason is that Graphite fonts tend to do multiple things per pass, while OT fonts do lots of passes, at least conceptually. That and integrating the shaper into the generated Graphite means it's all a little tricky. Graphite fonts tend to take a very different approach to describing the problem. OTOH you could well be one of the people who could work it out! > I am hesitant to try > writing one to convert GPOS tables; I have never understood why some > of my attached marks jump backwards as I type using a Graphite font. > (I suppose it might be an effect of the complex-first rule - is there a > compiler option to warn that it has taken effect?) There are a couple of things going on here. Did you see my email of last week that suggested a different way of doing glyph attachment? I think that could well solve your problem. But the core issue is that Graphite will quite happily attach across a base character which OT won't allow. So one has to be careful that base characters do not end up in you cNDia or whatever the class is that you ignore when looking for base to AP attachments. You may be using an older version of make_gdl (if you are using it at all) that had a bug in this area. > My motivation is that I have an OpenType Lanna script font that I want > the user (probably mostly me) to be able to customise using > typographical features. It works with HarfBuzz (and with m17n when > some of its bugs are fixed - not sure if the fixes are in a released > version yet), but it will be some time before Uniscribe/DirectWrite > will work with it. Unfortunately, readily available feature support for > OpenType seems only to be available in browsers. However, LibreOffice > (via an extension, I believe) does seem to have support for Graphite > features! LibreOffice needs no extension to support Graphite fonts. You may be thinking of an older extension that allows one to turn off the Graphite support. But that was back when Graphite was slow. It's now significantly faster that OT in nearly every font we've tried, so the need to turn off Graphite is gone and with it the need for the extension. > This conversion would be part of the font build process. I intend to > continue developing the OpenType font, and I want to automate the > process of converting it to Graphite. The nearest I can see getting is to extract various key classes and AP positions from the OT and then merge that with hand crafted core rule code, as normal. That would allow you to continue development in both. I say this, having woken up this morning intending to work on that very problem. So your request is timely. > An alternative that currently works, at least in LibreOffice, is to > associate different combination of features with languages. However, > as Martin Hosken has pointed out, this approach soon runs out of > languages, and requires a map from feature combinations to 'language'. An alternative would be to allow the same feature setting syntax we use in fonts, to work with the OT support in libreoffice. But that would take some coding from someone. Yours, Martin |
From: Richard W. <ric...@nt...> - 2015-06-17 17:10:40
|
Is there a tool around that will convert the GSUB, GPOS and GDEF tables of an OpenType font to Graphite? I am hesitant to try writing one to convert GPOS tables; I have never understood why some of my attached marks jump backwards as I type using a Graphite font. (I suppose it might be an effect of the complex-first rule - is there a compiler option to warn that it has taken effect?) My motivation is that I have an OpenType Lanna script font that I want the user (probably mostly me) to be able to customise using typographical features. It works with HarfBuzz (and with m17n when some of its bugs are fixed - not sure if the fixes are in a released version yet), but it will be some time before Uniscribe/DirectWrite will work with it. Unfortunately, readily available feature support for OpenType seems only to be available in browsers. However, LibreOffice (via an extension, I believe) does seem to have support for Graphite features! This conversion would be part of the font build process. I intend to continue developing the OpenType font, and I want to automate the process of converting it to Graphite. An alternative that currently works, at least in LibreOffice, is to associate different combination of features with languages. However, as Martin Hosken has pointed out, this approach soon runs out of languages, and requires a map from feature combinations to 'language'. Richard. |
From: Martin H. <mar...@si...> - 2015-06-09 06:55:21
|
Dear All, For years I have struggled with the attachment idiom that I use in Graphite fonts. The idiom is this: For a diacritic called A we would have a positioning rule of the form: cTakesADia cADia {attach{to=@1; with=AM; at=AS}; attached=1} / ^ _ opt4(cnTakesADia) _{attached==0}; This takes some explaining. What we are saying is that in input sequence consists of a cTakesADia (that's anything that an ADia glyph can attach to using its A attachment point) followed by up to 4 things that cannot have an ADia attaching to, followed by an ADia. If such a sequence is encountered, we attache the ADia to its base (the cTakesADia glyph), and then we search for another similar sequence (perhaps there is another diacritic involved, say a similar rule for cBDia). But in order not to get into an infinite loop we set a flag (user attribute) on the diacritic. It starts out 0 and gets set to 1 when attachment occurs. Then we test the constraint and fail the rule if the glyph in this sequence is already attached. This just feels wrong and inefficient. All this repeated testing and having to test a constraint. This is not satisfying. But there is a much simpler way: cADia {attach{to=@1; with=AM; at=AS}} / cTakesADia opt4(cnTakesADia) _; This works similarly and looks for an identical sequence. But the difference is that it starts at the diacritic and, in effect, scans backwards looking for something to attach it to. If it finds a cTakesADia, it does the attachment. It then advances to consider the next glyph in the string. No loops and no need for a constraint. The speedup seen is dependent on many factors, but one small test of Latin text involving lots of diacritics resulted in a 10% speedup. So it's not earth shattering, but I think it's something worth changing to in future. For one thing I think the above is simpler to understand. I hope to change make_gdl for its next release to work this way. Feel free to test it out in your fonts. If I'm wrong, then please let me know! Yours, Martin |
From: Jim B. <jim...@si...> - 2015-06-09 00:37:52
|
<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On several occassions, I have found fonts that I wanted to use for a minority language, but the designer had restricted it to supporting only the character sequences that occur in the national language. Before limiting a font by prohibiting certain sequences of characters, careful thought should be given to who may use the font. You may wish to design Font A to be used with Language X (i.e. your intended audience), but someone else may wish to use it with Language Y (your unintended audience). <br> <br> Of course, it is not possible to anticipate every potential use, or to invest the development time to support sequences for which there is no known demand. But at least one should not invest time to restrict sequences that someone else could plausibly use.<br> <br> Jim Brase<br> <br> <br> On 6/8/2015 7:12 AM, Sharon Correll wrote:<br> <blockquote cite="mid:557...@si..." type="cite"> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> The standard way to display an incorrect diacritic that has no appropriate base is to use a dotted circle - 25CC. For example:<br> <br> <img src="cid:par...@si..." alt=""><br> <br> So I would suggest inserting a dotted circle where you have no base character, or where there are two diacritics in a row (if they are not allowed to stack). An insertion rule for the latter would look like this:<br> <br> diac _ diac > @1 dottedCircle:3 @3;<br> <br> The ":3" means that the dotted circle is associated with the extra diacritic. So if you select the diacritic you will also select the circle.<br> <br> <br> <div class="moz-cite-prefix">On 6/8/2015 3:43 AM, Martin Hosken wrote:<br> </div> <blockquote cite="mid:20150608154356.22629531@sil-mh7" type="cite"> <pre wrap="">Dear John, </pre> <blockquote type="cite"> <pre wrap="">my name is Jon Brown and I am using graphite to program a font to behave correctly and I want to code the following effects, can you provide me with suggestions: (These two involve "smart" diacritics behavior) 1. If there is no base character, then diacritics mark will not display. I want diacritics mark to lock if first condition is not met. In other words, if the user presses a diacritics key and if the previous character is not a base character then the diacritics will not appear on the screen. 2. If there is already a base character followed by a diacritics then I want, then next diacritics to not display. I don't want diacritics overlapping. If the above cannot be achieved with font, can it be accomplished with programming a keyboard such as Tavultesoft keyman? </pre> </blockquote> <pre wrap=""><snip> As to diacritics not overlapping. That is a question the font and graphite can help with. I'm not sure which script you are interested in. But with Graphite you can have diacritics stack outwards from a base, or assemble themselves into any visual representation you want. But I would not advise implementing fonts that make things disappear (even though you can), because then it makes it nearly impossible for a user to fix their typing mistakes. And the typing mistakes, however you may make them look, are going to cause problems when it comes to searching. The strings will not be the same and so the search engine will seem to miss things. </pre> </blockquote> <br> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">------------------------------------------------------------------------------ </pre> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Silgraphite-fonts mailing list <a class="moz-txt-link-abbreviated" href="mailto:Sil...@li...">Sil...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts">https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts</a> </pre> </blockquote> <br> </body> </html> |
From: Sharon C. <sha...@si...> - 2015-06-08 12:39:00
|
<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> The standard way to display an incorrect diacritic that has no appropriate base is to use a dotted circle - 25CC. For example:<br> <br> <img src="cid:par...@si..." alt=""><br> <br> So I would suggest inserting a dotted circle where you have no base character, or where there are two diacritics in a row (if they are not allowed to stack). An insertion rule for the latter would look like this:<br> <br> diac _ diac > @1 dottedCircle:3 @3;<br> <br> The ":3" means that the dotted circle is associated with the extra diacritic. So if you select the diacritic you will also select the circle.<br> <br> <br> <div class="moz-cite-prefix">On 6/8/2015 3:43 AM, Martin Hosken wrote:<br> </div> <blockquote cite="mid:20150608154356.22629531@sil-mh7" type="cite"> <pre wrap="">Dear John, </pre> <blockquote type="cite"> <pre wrap="">my name is Jon Brown and I am using graphite to program a font to behave correctly and I want to code the following effects, can you provide me with suggestions: (These two involve "smart" diacritics behavior) 1. If there is no base character, then diacritics mark will not display. I want diacritics mark to lock if first condition is not met. In other words, if the user presses a diacritics key and if the previous character is not a base character then the diacritics will not appear on the screen. 2. If there is already a base character followed by a diacritics then I want, then next diacritics to not display. I don't want diacritics overlapping. If the above cannot be achieved with font, can it be accomplished with programming a keyboard such as Tavultesoft keyman? </pre> </blockquote> <pre wrap=""> <snip> As to diacritics not overlapping. That is a question the font and graphite can help with. I'm not sure which script you are interested in. But with Graphite you can have diacritics stack outwards from a base, or assemble themselves into any visual representation you want. But I would not advise implementing fonts that make things disappear (even though you can), because then it makes it nearly impossible for a user to fix their typing mistakes. And the typing mistakes, however you may make them look, are going to cause problems when it comes to searching. The strings will not be the same and so the search engine will seem to miss things. </pre> </blockquote> <br> </body> </html> |
From: Martin H. <mar...@si...> - 2015-06-08 09:12:28
|
Dear John, > my name is Jon Brown and I am using graphite to program a font to behave > correctly and I want to code the following effects, can you provide me with > suggestions: > > (These two involve "smart" diacritics behavior) > 1. If there is no base character, then diacritics mark will not display. I > want diacritics mark to lock if first condition is not met. In other words, > if the user presses a diacritics key and if the previous character is not a > base character then the diacritics will not appear on the screen. > > 2. If there is already a base character followed by a diacritics then I > want, > then next diacritics to not display. I don't want diacritics overlapping. > > If the above cannot be achieved with font, can it be accomplished with > programming a keyboard such as Tavultesoft keyman? Both of these can be achieved in a font, but are almost certainly not what you want to do in a font. A font should do its best to show you what is in the underlying data stream as beautifully as it can, but including all the faults so that a user can fix them. The input method (keyboard), on the other hand, can and perhaps should be designed to encourage people to enter good data. This would include things like stopping them typing a diacritic if there is no base or limiting which diacritics they can type after each other, etc. Tavultesoft's Keyman is an excellent tool to allow you to write keyboards that have rules in them to control such things. You can make the keyboard beep if the user presses a 'wrong' key. You can reorder sequences already entered. Etc. As to diacritics not overlapping. That is a question the font and graphite can help with. I'm not sure which script you are interested in. But with Graphite you can have diacritics stack outwards from a base, or assemble themselves into any visual representation you want. But I would not advise implementing fonts that make things disappear (even though you can), because then it makes it nearly impossible for a user to fix their typing mistakes. And the typing mistakes, however you may make them look, are going to cause problems when it comes to searching. The strings will not be the same and so the search engine will seem to miss things. HTH, Yours, Martin Hosken |
From: Martin H. <mar...@si...> - 2015-03-07 03:35:55
|
Dear Jon, > my name is Jon Brown and I am using graphite to program a font to behave > correctly and I want to code the following effects, can you provide me with > suggestions: > > (These two involve "smart" diacritics behavior) > 1. If there is no base character, then diacritics mark will not display. I > want diacritics mark to lock if first condition is not met. In other words, > if the user presses a diacritics key and if the previous character is not a > base character then the diacritics will not appear on the screen. > > 2. If there is already a base character followed by a diacritics then I > want, > then next diacritics to not display. I don't want diacritics overlapping. The easiest way to achieve this in GDL is to have a masking rule that keeps the diacritics and then otherwise delete them: cBase cDiacritic > @1 @2; cDiacritic > _; The first rule says: if there is a base and a diacritic, do nothing The second rule is shorter and so will not fire unless the first rule fails. It says delete any cDiacritic. But this will give warnings. So a better second rule is: ANY cDiacritic > @1:(1 2) _; This says: any glyph followed by a diacritic has the diacritic deleted and the glyph associated with both underlying characters. > If the above cannot be achieved with font, can it be accomplished with > programming a keyboard such as Tavultesoft keyman? Having shown how to do this in Graphite, I would recommend not doing this in the font. I would recommend encouraging people to enter good data in the first place. Tavultesoft Keyman would do a fine job: begin Unicode > use(main) store(cBase) c list of base chars unicode values store(cBaseK) c corresponding list of keystroks for the base chars store(cDia) c list of diacritic unicode codes store(cDiaK) c corresponding list of keystrokes for diacritics group(main) using keys + cBaseK > index(cBase, 1) cBase + cDiaK > context index(cDia, 2) + cDiaK > beep Should just about cover it. Obviously this is just a code outline fragment. The reason for using the keyboard is that if people type stuff into their text and it doesn't display, it makes it nearly impossible to delete it and clear it up and also you won't know why searching will not work properly. A better solution is to flag the problem in the font using a dotted circle: cBase cDiacritic; _ cDiacritic > g25CC:(1 2) @2; For those wondering why I didn't do: _ > g25CC / _ cDiacritic; The problem is that that would insert an infinite (limited down to 5) dotted circles before a diacritic since the cursor would not advance beyond the diacritic. HTH, GB, Martin |
From: A BC <eg...@gm...> - 2015-03-06 21:26:59
|
Hello, my name is Jon Brown and I am using graphite to program a font to behave correctly and I want to code the following effects, can you provide me with suggestions: (These two involve "smart" diacritics behavior) 1. If there is no base character, then diacritics mark will not display. I want diacritics mark to lock if first condition is not met. In other words, if the user presses a diacritics key and if the previous character is not a base character then the diacritics will not appear on the screen. 2. If there is already a base character followed by a diacritics then I want, then next diacritics to not display. I don't want diacritics overlapping. If the above cannot be achieved with font, can it be accomplished with programming a keyboard such as Tavultesoft keyman? |
From: Martin H. <mar...@si...> - 2014-02-04 03:27:16
|
Dear Shriramana, > As per the Graphite behaviour seen via HB and XeTeX (I haven't trained > myself to use gr2fonttest directly much yet) I understand that when a glyph > has an advancewidth, but it is attached+positioned w.r.t another glyph, > then the advancewidth is voided and unless any composite metrics are set in > terms of kerning etc, the advancewidth of the base is the only remaining > one. No this is not what graphite does. Herewith my best take on the behaviour: When a diacritic is added to a base, the distance the origin of the diacritic is to the left of the base origin is calculated. The base position (and therefore the diacritic position with it) is advanced by this amount. The effect now is that the combined cluster is shifted (along with its advance) such that the left most component (diacritic or base) of the cluster is at the cluster start (the origin of the base if there were no diacritics). And if that isn't confusing enough, for the purposes of right to left rendering, this cluster shifting only happens if the advance of the diacritic is non-zero. In addition, if the diacritic has a non-zero advance, the same trick is applied to the advance for the cluster. If the positioned advance (origin + advance) of the diacritic is to the right of the advance of the base, the cluster advance is increased to this amount. So, the 'some space' is clearly defined and under your control. > For instance, in Kannada, when one has a consonant cluster of many > consonants, the sub-base consonants start moving to the right to avoid > extreme vertical advance. So the font maker may have a reason for providing > a conjoining form a non-zero advance width. Cancelling it automatically and > having to reset it to its original value (which is however not recoverable > in GDL programmatically AFAICS) is inappropriate IMHO. If the font maker > wants a glyph to have a zero default advancewidth, then s/he should set > that advancewidth to zero. It can always be made non-zero in the GDL. In addition. If you were right attaching some diacritic to a base and you wanted to treat that right attached diacritic as if it were a base and allow the cursor to appear between them (at the advance of the base) then you would set insert=1 on the diacritic when you attached it. Not sure if that is what you are wanting to do. > As such, even though a glyph will always be combined as per the GDL, Gr > should not cancel its advancewidth. This will help enforce consistent font > metric setting on part of the font maker. > > Thoughts? It really does do what you want it to do :) > > As for the conversation below, it is not clear to me why Gr2 adds "some > guard space". The point of Gr is providing full control (and > responsibility) of all positioning/spacing issues to the font maker. IMHO > Gr should not make any assumptions on behalf of the user as to what space > should be added where. > > Also, what was the outcome of the conversation between Martin and Sharon > mentioned below? > > No. For Graphite1, if the advance-width is non-zero, it will affect > > the advance of the base character. If the advance width is zero, the > > metrics of the diacritic will be ignored as far as positioning the > > base. (It should be possible to set the advanced width to zero using > > GDL, even if the font uses something different.) Yup. Graphite 2 does that now too, but only for rtl. The reason we don't disable left guard space protection for ltr is that you can achieve what you want by positioning your glyph in relation to its origin. For rtl that can sneak up and bite you so we allow for turning off the guard space protection. I bet you wish you hadn't asked now ;) Yours, Martin |
From: Shriramana S. <sa...@gm...> - 2014-02-03 05:30:30
|
Hello. This is w.r.t an earlier conversation of mine on this list appended to this mail. This is also in relation to https://bugs.freedesktop.org/show_bug.cgi?id=52575. As per the Graphite behaviour seen via HB and XeTeX (I haven't trained myself to use gr2fonttest directly much yet) I understand that when a glyph has an advancewidth, but it is attached+positioned w.r.t another glyph, then the advancewidth is voided and unless any composite metrics are set in terms of kerning etc, the advancewidth of the base is the only remaining one. However, it is not clear to me whether that is the appropriate behaviour. It seems to me that if a font maker wants a glyph to be non-spacing then s/he should not provide an advancewidth at all. One assumes that just because a glyph is positioned w.r.t its base, it becomes non-spacing. That need not be the case always. For instance, in Kannada, when one has a consonant cluster of many consonants, the sub-base consonants start moving to the right to avoid extreme vertical advance. So the font maker may have a reason for providing a conjoining form a non-zero advance width. Cancelling it automatically and having to reset it to its original value (which is however not recoverable in GDL programmatically AFAICS) is inappropriate IMHO. If the font maker wants a glyph to have a zero default advancewidth, then s/he should set that advancewidth to zero. It can always be made non-zero in the GDL. As such, even though a glyph will always be combined as per the GDL, Gr should not cancel its advancewidth. This will help enforce consistent font metric setting on part of the font maker. Thoughts? As for the conversation below, it is not clear to me why Gr2 adds "some guard space". The point of Gr is providing full control (and responsibility) of all positioning/spacing issues to the font maker. IMHO Gr should not make any assumptions on behalf of the user as to what space should be added where. Also, what was the outcome of the conversation between Martin and Sharon mentioned below? Shriramana. On Sun, Jul 29, 2012 at 1:54 AM, Sharon Correll <sha...@si...>wrote: > On 7/28/2012 12:08 PM, Shriramana Sharma wrote: > > BTW do I correctly understand that if a (diacritic) glyph is attached > > to another using attach.at and .with, and the advancewidth of the > > attached (diacritic) glyph is in fact non-zero in the font, then after > > attachment such advancewidth is ignored? > > No. For Graphite1, if the advance-width is non-zero, it will affect > the advance of the base character. If the advance width is zero, the > metrics of the diacritic will be ignored as far as positioning the > base. (It should be possible to set the advanced width to zero using > GDL, even if the font uses something different.) > > But there is some difference between Graphite1 and Graphite2. > Graphite2 automatically adds some guard space for the diacritic, even > when the advance-width is zero. Martin and I have just been discussing > this difference recently. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा |
From: Martin H. <mar...@si...> - 2013-11-13 08:21:29
|
Dear Krzysztof, > PS. Your hints make me think about redesigning my font to less based on > glyphs to more based on rules. As perhaps in most of alphabets, we can find > returning fragments of glyphs, that can be glued together into complete > glyph by rules of positioning. That might be interesting experiment, and > such a font could be easier to be graphically redesigned, as it would have > to redraw only these parts of glyphs. Of course, first I want to finish > this, what I had begun. This raises an issue that needs to be more widely understood. GDL supports the concept of pseudo glyphs, and they can be really useful. But there is a situation where they can become problematic and that is where the pseudo glyph is given a Unicode value. In effect the GDL author is trying to add an entry into the cmap to a pseudo glyph. Given a string of characters containing a character for which there is a pseudo glyph, the graphite engine will do the right thing. The problem is that in the places where Graphite runs, there is also another dynamic going on which is font linking. If a character is missing from a font, the application will take remedial steps either to find a glyph for that one character from another font, or even switch font from there on. The applications often do this without consulting Graphite at all. They look in the cmap of the font, find that there is no entry and so assume the font doesn't support the character. They then break the run at that point and Graphite never gets to see the presumed missing character for it to do pseudoglyph replacement on it. So my advice is that people not use pseudo-glyphs which specify a Unicode cmap entry. Instead add a dummy glyph to the font and put a real entry in the cmap, using some other tool such as a font editor like fontforge. Yours, Martin |