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: Carsten B. <ca...@gm...> - 2012-08-16 16:12:00
|
Hello, I've run into a strange behavior while experimenting with my font. See what's the problem here: <https://github.com/carbeck/tagatibookg/issues/3>. Is there any explanation for that? After some more trying I found out that LibreOffice also does that with left-aligned text, it's more likely to happen towards the end of a line, and the severity of the effect also seems to depend on the chosen font size and/or zoom level. Is there anything to counter this effect? Thanks Carsten -- Tagāti Book G: http://github.com/carbeck/tagatibookg |
From: Carsten B. <ca...@gm...> - 2012-08-13 16:55:42
|
Hi, I've just uploaded my font project regarding which I was asking questions recently to Github, so whoever wants to check out the whole thing can do so now. My Graphite code's probably not very elegant, but at least things work now as I desired. You can find the link in my signature below. Regards Carsten -- Tagāti Book G: http://github.com/carbeck/tagatibookg |
From: Sharon C. <sha...@si...> - 2012-08-08 21:05:42
|
For those who are interested in experimenting with Firefox's capability to handle Graphite features, NRSI has released a "maintenance release" of all our Roman fonts--Doulos, Charis, Andika, and Gentium. The only change in this maintenance release is a change in the Graphite feature identifiers from integers to 4-character alphanumeric tags. This was required because although Mozilla Firefox has now implemented support for Graphite, feature identifiers only work if they are 4-character alphanumeric tags. If you would like to use these features in Firefox, this webpage (http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_firefox) describes how to access font features. The font download contains a document (fontname-features.pdf) which describes the old and new feature identifiers. Existing documents (such as those created by LibreOffice/OpenOffice) which use the old identifiers will need to be changed to use the new identifiers. Future releases will use the new 4-character alphanumeric tags. Unless you wish to use the font features in Mozilla Firefox, you may continue using your officially released fonts. The fonts are available here: http://scripts.sil.org/DoulosSIL_download#4112 http://scripts.sil.org/CharisSIL_download#4112 http://scripts.sil.org/Gentium_download#1510 http://scripts.sil.org/Andika_download#1004 Sharon Correll (on behalf of the Lorna Priest and the NRSI Global Scripts Support team) |
From: Martin H. <mar...@si...> - 2012-08-07 03:03:35
|
Dear All, This is more of a mini article/blog post than a message. Running Graphite is slow. But then so is running something like OpenType. It's not that Graphite itself is slow, but the very process of doing complex shaping is slow. In order to speed up their applications, developers write code to cache results so that they don't have to recalculate them all the time. Rather than caching full segments, which would result in a cache with lots of entries and few hits (reuse of previous cache entries), developers split segments into smaller strings to increase the likelihood that those substrings are already in the cache. The most popular way to split strings is on the space character.* If strings are being chopped on spaces, what does that do for fonts that have rules involving the space glyph? We call such fonts space contextual fonts. There are a number of such fonts and the short answer is that in applications that chop words on spaces, these fonts don't work properly. A more refined solution is to say: let's see if the font is a space contextual one. If it is, then we'll not split the segment, and we'll just lose the power of caching and run slower. For those fonts that really need the space contextuality, this is probably a price worth paying. The danger, though, is that space contextuals can slip into fonts that otherwise would not need or want them. For example, in an Arabic font, someone might write a rule that says: cIsol > cFin / _ cNonLetter and include the space glyph in the class cNonLetter. This makes a font space contextual. The reason being is that while the font does not need the space to be there, it will report to the application that spaces are used in rules and therefore the font is space contextual and all caching will be turned off. The upshot of this is that you are strongly advised to avoid using space glyphs in your GDL if you can avoid it. It's not that the font won't work, although in some cases it may not work as planned, but that it will slow down your font considerably. For those wishing to find out whether their font is space contextual, here is a manual way to find out (although perhaps we will add a warning to the compiler for people). First build your font with the debug files: grcompiler -D myfile.gdl input.ttf output.ttf, to get the dbg_*.txt files. Then look in dbg_cmap.txt to find the glyphid for the space character (usually glyphid of 3). Then go through the dbg_fsm.txt and check each pass (excluding the linebreak pass) to see whether glyphid 3 is listed as having a column mapping. If it is and it maps to a value other than 0, then that pass makes contextual use of the space glyph and you should dig deeper. BTW before people see this as a Graphite only problem, the exact same problem occurs in OpenType based applications which use caching. Yours, Martin Hosken * There are other options on how to split up strings but they are all have even worse problems. |
From: Carsten B. <ca...@gm...> - 2012-08-06 07:29:07
|
Am Mo 06 Aug 2012 09:03:54 CEST schrieb Shriramana Sharma: > Well if it came to typing everything out, this is only a little less > cumbersome than the full version. I typed it all out in the end. And while that certainly looks more cumbersome than a few lines of determining character properties on the fly, it's still just 30-odd lines like the one below, so that's entirely manageable. U+0070 AnyVirama U+0070 > @1:(1 2) _ U+0313; // PA (key: p) Carsten -- Currently developing Tagāti Book G: http://bit.ly/Ml5xb8 |
From: Shriramana S. <sa...@gm...> - 2012-08-06 07:04:21
|
Hi Martin -- thanks for your reply. On Mon, Aug 6, 2012 at 9:09 AM, Martin Hosken <mar...@si...> wrote: > One option might be to add a slot attribute .glyphid or somesuch that could be tested: > cons > geminate / cons _ {glyphid == @1.glyphid}; Another option might be to allow some kind of foreach construct in the language. But perhaps that would be somewhat deviating from the existing language model. And without LHS referencing, it still would not be useful for much more than geminates. (Neither would glyphid slot attributes.) Although, honestly I cannot imagine what real case other than geminates would need to be supported. In my Tamil Brahmi GDL, I had to do 18 series of: KA + clsVowelSigns -> KA-series NGA + clsVowelSigns -> NGA-series and so on. (But that was because the glyph developer had made pre-composed glyphs which I realized later are not necessary.) But if GDL had for and treated classes like arrays, we could always use a two dimensional array: for x = 1 to 18: for y = 1 to 12: cons[x] vs[y] > syllable[x][y] ;-) > #define GEM(x, y) x > y / x _ > GEM(g_a, g_a_gem); > GEM(g_b, g_b_gem); > etc. Well if it came to typing everything out, this is only a little less cumbersome than the full version. I'm sure right now we can use Python (or some such scripting language) to output the requisite statements using *its* for loop. -- Shriramana Sharma |
From: Martin H. <mar...@si...> - 2012-08-06 03:39:47
|
Dear Shriramana, > Is there a prohibitive reason by which it is not possible to use > referencing in the context? I seem to have encountered a situation > similar to Carsten's some time back... There is nothing to stop us making a decision to support this. But the cost would be considerable and outweighs the benefit. The regular expression engine is deterministic and adding back references would cause a radical change involving rewriting nearly everything in order to turn the regular expression non deterministic. One option might be to add a slot attribute .glyphid or somesuch that could be tested: cons > geminate / cons _ {glyphid == @1.glyphid}; But that would take a while to appear (since it would have to be added to the compiler and the engine and then trickle down via releases) and be pretty slow, so perhaps you would be better off with doing something like: #define GEM(x, y) x > y / x _ GEM(g_a, g_a_gem); GEM(g_b, g_b_gem); etc. That will run much faster than any constraint test would. Yours, Martin |
From: Shriramana S. <sa...@gm...> - 2012-08-06 03:01:38
|
Hi Sharon (or Martin and others), On Sun, Aug 5, 2012 at 6:22 PM, Carsten Becker <ca...@gm...> wrote: > Since according to the documentation it's not possible to use > referencing with @ or $ on the LHS Is there a prohibitive reason by which it is not possible to use referencing in the context? I seem to have encountered a situation similar to Carsten's some time back... @Carsten: I think it would be $ and not @ too which references the whole glyph and not just its index. -- Shriramana Sharma |
From: Sharon C. <sha...@si...> - 2012-08-05 19:30:41
|
There's not really a good way built into the language--normally you'd have to list all the pairs using separate rules. But here's another idea: table(glyph) g_b {type = 1}; g_c {type = 2}; g_d {type = 3}; g_f {type = 4}; etc. Consonant = (g_b, g_c, g_d, g_f, ...); endtable; table(sub) Consonant Consonant > Consonant Gemination_Diacritic / _ {type == @2.type} _ ; endtable; Actually making a set of separate rules is probably slightly more efficient--using a finite state machine to match rules is more efficient than testing the glyph attribute. But maybe the code isn't as neat. Although either way you have to make a long list. On 8/5/2012 7:52 AM, Carsten Becker wrote: > Hi, > > I've got another question regarding GDL and substitution: How do I match > and replace two subsequent identical characters? What I want to do is > basically this: > > Consonant Same_Consonant > Consonant Gemination_Diacritic > > Since according to the documentation it's not possible to use > referencing with @ or $ on the LHS, I'm a little stumped. Is this maybe > solvable with some flag, or a recursive rule? > > Regards > Carsten > |
From: Carsten B. <ca...@gm...> - 2012-08-05 12:52:49
|
Hi, I've got another question regarding GDL and substitution: How do I match and replace two subsequent identical characters? What I want to do is basically this: Consonant Same_Consonant > Consonant Gemination_Diacritic Since according to the documentation it's not possible to use referencing with @ or $ on the LHS, I'm a little stumped. Is this maybe solvable with some flag, or a recursive rule? Regards Carsten -- Currently developing Tagāti Book G: http://bit.ly/Ml5xb8 |
From: Carsten B. <ca...@gm...> - 2012-08-01 22:52:18
|
Am Mi 01 Aug 2012 23:56:08 CEST schrieb Carsten Becker: > The diacritics I was trying to attach are all > relatively at the start of the Private Use Area, i.e. U+E000 upwards. Correction: U+E010 upwards. Attaching characters used as diacritics between U+E000 and U+E00F works for me, even if both passes (diacritic-to-base and diacritic-to-diacritic) are involved. I've updated the testing page I have already linked previously to demonstrate these findings (scroll to the bottom). I hope someone can confirm what I'm experiencing. Carsten |
From: Carsten B. <ca...@gm...> - 2012-08-01 21:56:17
|
Am Mi 01 Aug 2012 17:04:34 CEST schrieb Carsten Becker: > On the page with the example I posted yesterday I also included some > notes about things that don't work. I really hope it's not just me. After some more experimenting, I found out that the problem with Firefox is not due to handling attachment with two passes itself, but Unicode codepoints. The diacritics I was trying to attach are all relatively at the start of the Private Use Area, i.e. U+E000 upwards. I *assume* that this is a bug in how Graphite is compiled into Firefox rather than a bug in Graphite itself, since attaching those diacritics works flawlessly in Libre Office, as I said. Carsten |
From: Carsten B. <ca...@gm...> - 2012-08-01 15:04:42
|
(This was meant to go to the list, not just to Sharon. I clicked "Send" too quickly.) On 01.08.2012 16:16, Sharon Correll wrote: > You do have Graphite turned on in Firefox, right? You have to > deliberately do that: Yeah, I know. I had it turned on in both Ubuntu and Windows already. The Graphite testing page works for me, which is why I wondered. Even the paragraph that tests my locally installed version of Padauk does. Though looking at the GDL source file, Padauk does all positioning in one pass, too, and reserves the second pass for kerning ... On the page with the example I posted yesterday I also included some notes about things that don't work. I really hope it's not just me. Now I'll have to figure your single-pass solution after all! Carsten |
From: Sharon C. <sha...@si...> - 2012-08-01 14:16:23
|
You do have Graphite turned on in Firefox, right? You have to deliberately do that: http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_firefox On 7/31/2012 3:24 PM, Carsten Becker wrote: > On 31.07.2012 21:22, Sharon Correll wrote: > >> :-( I've never heard of a problem along those lines with Firefox. The >> only bug I know of is that features are not recognized if they don't >> have exactly 4-character IDs (numbers don't work, nor do 3-character IDs). > I have no idea why, but if I import the font into Firefox with > @font-face rather than drawing the data from ~/.fonts or > C:\Windows\Fonts respectively, it works. > > I'm too tired now to look at your suggestions regarding single passes > (thanks for your patience with me, however!), but I'll try to give it a > go tomorrow – or at least try to comprehend it! > > Here's some testing/demonstration: > <http://dl.dropbox.com/u/8026017/tagatibookg-test/tagatibookg-test.html> > > Regards > Carsten > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Silgraphite-fonts mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts |
From: Carsten B. <ca...@gm...> - 2012-07-31 20:24:53
|
On 31.07.2012 21:22, Sharon Correll wrote: > :-( I've never heard of a problem along those lines with Firefox. The > only bug I know of is that features are not recognized if they don't > have exactly 4-character IDs (numbers don't work, nor do 3-character IDs). I have no idea why, but if I import the font into Firefox with @font-face rather than drawing the data from ~/.fonts or C:\Windows\Fonts respectively, it works. I'm too tired now to look at your suggestions regarding single passes (thanks for your patience with me, however!), but I'll try to give it a go tomorrow – or at least try to comprehend it! Here's some testing/demonstration: <http://dl.dropbox.com/u/8026017/tagatibookg-test/tagatibookg-test.html> Regards Carsten |
From: Sharon C. <sha...@si...> - 2012-07-31 19:24:12
|
Oops, I should have written that to use the NOT... macros, but you get the idea. On 7/31/2012 2:22 PM, Sharon Correll wrote: > #define isattached user1 > takes_upper AnyTopDiacritic {attach...; isattached =1} / _ ^ > BOTSEQ _ {isattached == 0}; > takes_lower AnyBotMidDiacritic {attach...; isattached =1} / _ ^ > TOPorBRTSEQ _ {isattached == 0}; > takes_lower AnyBotRightDiacritic {attach...; isattached =1} / _ ^ > TOPorBMIDSEQ _ {isattached == 0}; |
From: Sharon C. <sha...@si...> - 2012-07-31 19:22:56
|
On 7/31/2012 12:52 PM, Carsten Becker wrote: > Hi Sharon, > > On 30.07.2012 22:36, Sharon Correll wrote: >> Oops, HTML or something got me! There probably need to be spaces >> around the caret. That's the key magic that makes the chaining happen. >> >> takes_upper upperdiac {attach {to=@1; at=TopS; with=TopM}} / _ >> LOWERSEQ ^ _; > I'm afraid I can't get that to work like my two-pass solution for some > reason. As far as I can tell, in my case I'd have to change the rules > this way (all the indented lines should be a single one): > > takes_upper = ( clsCons, AnyTopDiacritic ); > takes_lower = ( clsCons, AnyBotDiacritic, clsDiaBotRight ); > > takes_upper AnyTopDiacritic { attach { to=@1; at=topAnch; > with=attGeneric }} / _ BOTSEQ ^ _; > takes_lower AnyBotMidDiacritic { attach { to=@1; at=botAnchMid; > with=attGeneric }} / _ TOPSEQ BOTSEQ ^ _; > takes_lower clsDiaBotRight { attach { to=@1; at=botAnchRight; > with=attGeneric }} / _ TOPSEQ ^ _; You need to move the caret to *before* the BOTSEQ, so the processing goes back and handles the bottom diacritics. In general, you want to make sure that each rule "consumes" only one character at a time, otherwise some will get skipped. Also there is a problem with the second rule: including BOTSEQ (which I assume means "optional bottom diacritics") as part of the context means that the last bottom diacritic will be attached first, since the longest rule gets matched first. You probably need two optional sequences, say BOTMIDSEQ and BOTRTSEQ. And notice that optional items imply that the top diacritics come first, before the bottom ones (contrary to Unicode specification, but I guess it's up to you in this case). Also you'd probably need to include tests to keep the same rules from being fired over and over. I would do it something like this: #define NOTTOPSEQ [ NotTopDiac NotTopDiac?]? // these sequences can be longer... #define NOTBOTRIGHTSEQ [ NotBotRightDiac NotBotRightDiac?]? #define NOTBOTMIDSEQ [ NotBotMidDiac NotBotMidDiac?]? NotTopDiac = (clsDiaBotMid, clsDiaBotRight); NotBotRightDiac = (clsDiaTop, clsDiaBotMid); NotBotMidDiac = (clsDiaTop, clsDiaBotRight); takes_upper AnyTopDiacritic {attach...} / _ ^ NOTTOPSEQ _ {attach.to == 0}; takes_lower AnyBotMidDiacritic {attach...} / _ ^ NOTBOTMIDSEQ _ {attach.to == 0}; takes_lower AnyBotRightDiacritic {attach...} / _ ^ NOTBOTRIGHTSEQ _ {attach.to == 0}; Something like that anyway. Note that to make sure it can handle all the combinations, the optional sequences need to be very flexible. You might be able to simplify if you can assume that the diacritics appear in a particular order. The tests will generate warnings; it's a slightly unconventional thing to do, but it works. Or you can use a user-defined slot attribute, eg: #define isattached user1 takes_upper AnyTopDiacritic {attach...; isattached =1} / _ ^ BOTSEQ _ {isattached == 0}; takes_lower AnyBotMidDiacritic {attach...; isattached =1} / _ ^ TOPorBRTSEQ _ {isattached == 0}; takes_lower AnyBotRightDiacritic {attach...; isattached =1} / _ ^ TOPorBMIDSEQ _ {isattached == 0}; Just some ideas. Doing it in two passes is fine, but keep in mind that every pass slows down the processing. So if performance were an issue, one pass would be preferable if you could make it work. > FWIW, I've also tested my font in Firefox 14 now that Firefox has been > supporting Graphite since a couple of versions back. However, it will > only follow the rules in the first positioning pass, so it won't do > diacritic-to-diacritic attachment for me. I've tested this on both > Ubuntu 12.04 and Windows XP (there with Firefox 16.0.1a). Is this a bug? > Everything works fine in Libre Office 3.5.5.3. :-( I've never heard of a problem along those lines with Firefox. The only bug I know of is that features are not recognized if they don't have exactly 4-character IDs (numbers don't work, nor do 3-character IDs). |
From: Carsten B. <ca...@gm...> - 2012-07-31 17:52:17
|
Hi Sharon, On 30.07.2012 22:36, Sharon Correll wrote: > Oops, HTML or something got me! There probably need to be spaces > around the caret. That's the key magic that makes the chaining happen. > > takes_upper upperdiac {attach {to=@1; at=TopS; with=TopM}} / _ > LOWERSEQ ^ _; I'm afraid I can't get that to work like my two-pass solution for some reason. As far as I can tell, in my case I'd have to change the rules this way (all the indented lines should be a single one): takes_upper = ( clsCons, AnyTopDiacritic ); takes_lower = ( clsCons, AnyBotDiacritic, clsDiaBotRight ); takes_upper AnyTopDiacritic { attach { to=@1; at=topAnch; with=attGeneric }} / _ BOTSEQ ^ _; takes_lower AnyBotMidDiacritic { attach { to=@1; at=botAnchMid; with=attGeneric }} / _ TOPSEQ BOTSEQ ^ _; takes_lower clsDiaBotRight { attach { to=@1; at=botAnchRight; with=attGeneric }} / _ TOPSEQ ^ _; However, this only stacks the top-diacritics correctly, while ignoring the bottom ones. Also, there is a twist in that there are two groups of diacritics that can be attached beneath consonants, one in the middle under them, one at the right side. It's possible to attach further bottom-middle diacritics to either group. My two-pass solution may not be as elegant as doing everything in one pass, but at least diacritic attachment works reliably for any possible combination: pass(1) // First-level attachment clsCons AnyTopDiacritic { attach { to=@1; level=1; at=topAnch; with=attGeneric }; user1 = 1 } / ^ _ BOTSEQ _ { user1 == 0 }; clsCons AnyBotMidDiacritic { attach { to=@1; level=1; at=botAnchMid; with=attGeneric }; user1 = 1 } / ^ _ TOPSEQ _ { user1 == 0 }; clsCons clsDiaBotRight { attach { to=@1; level=1; at=botAnchRight; with=attGeneric }; user1 = 1 } / ^ _ TOPSEQ _ { user1 == 0 }; endpass; // 1 pass(2) // Second-level attachment (diacritic-to-diacritic) AnyTopDiacritic AnyTopDiacritic { attach { to=@1; level=2; at=topAnch; with=attGeneric }; user1 = 1 } / ^ _ BOTSEQ _ { user1 == 0 }; (AnyBotMidDiacritic clsDiaBotRight) AnyBotMidDiacritic { attach { to=@1; level=2; at=botAnch; with=attGeneric }; user1 = 1 } / ^ _ TOPSEQ _ { user1 == 0 }; endpass; // 2 FWIW, I've also tested my font in Firefox 14 now that Firefox has been supporting Graphite since a couple of versions back. However, it will only follow the rules in the first positioning pass, so it won't do diacritic-to-diacritic attachment for me. I've tested this on both Ubuntu 12.04 and Windows XP (there with Firefox 16.0.1a). Is this a bug? Everything works fine in Libre Office 3.5.5.3. Regards Carsten |
From: Sharon C. <sha...@si...> - 2012-07-30 20:36:59
|
Oops, HTML or something got me! There probably need to be spaces around the caret. That's the key magic that makes the chaining happen. takes_upper upperdiac {attach {to=@1; at=TopS; with=TopM}} / _ LOWERSEQ ^ _; On 7/30/2012 3:32 PM, Sharon Correll wrote: > takes_upperupperdiac {attach {to=@1; at=TopS; with=TopM}} / _ LOWERSEQ^ _; |
From: Sharon C. <sha...@si...> - 2012-07-30 20:33:01
|
On 7/28/2012 5:24 AM, Carsten Becker wrote: > The problem was how to stack diacritics on diacrtics, but I've > generalized my rules (a group for all top diacritics, and another for > all bottom diacritics) and divided them into passes now, so that in the > first pass, any diacritic is placed over/below a consonant matrice, and > then in a second pass, diacritics can be attached to the syllable block > from the first pass. The GDL snippets from the Graphite page were > helpful, too. The example of stacking diacritics on the GDL snippets page shows how to do it in one pass: http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_codeSnippets#fa1aea6b Note that the takes_upper class includes both bases and other upper diacritics. So the single rule handles the chain: takes_upperupperdiac {attach {to=@1; at=TopS; with=TopM}} / _ LOWERSEQ^ _; You can just take out the references to lower diacritics if you don't have any. |
From: Shriramana S. <sa...@gm...> - 2012-07-30 04:35:01
|
On Mon, Jul 30, 2012 at 8:37 AM, Martin Hosken <mar...@si...> wrote: > Having reserved the right to modify documentation to describe reality even if that reality isn't what people want to hear, I have checked in a fix Hi Martin -- I hope you have not taken amiss my insistence on a consistent and meaningful behaviour. Sorry if I have done/said anything wrong. You of course have the right to write the source code and documentation in whatever way you think is appropriate, but I am sure you will also listen to users of your library as to what behaviour is expected and what not. > so that your unique (I have never known anyone want to do what you want) I think that's because so far there apparently haven't been many implementations of Indic scripts using Graphite. (Of course you people have done Padauk Myanmar, but AFAIK there are no Vedic texts in Myanmar as there are in *Indian* Indic scripts!) And in Indic scripts, I think it is a fair expectation for vowel signs (positioned in whatever direction of the base) to be attached to consonants. It is NOT a fair expectation for consonants to be attached to vowel signs because that *just doesn't make sense*! :-) I have been banking on Graphite to support me in my work on creating (encodings and) fonts for rare Indic scripts which are not going to be supported in OT in the foreseeable future -- I hope you people are with me on that. > situation is handled consistently between gr2 and gr1. Now you can go and solve your problem in lots of different ways. Well, given that gr1 is practically frozen, I suppose you mean by "consistently between gr2 and gr1" that gr2 no longer assumes that the base is at x=0. Are the changes to slot.cpp seen at http://hg.palaso.org/graphitedev/rev/ad1e222b3b16#l4.1 the changes you refer to? Thanks, and once again, I'm sorry if I said anything wrong. -- Shriramana Sharma |
From: Martin H. <mar...@si...> - 2012-07-30 03:07:56
|
Dear Shriramana, > Now please don't tell me that the documentation should be changed. The > documentation is correct and describes exactly what is expected by the > user. It is the implementation that should be changed accordingly. Having reserved the right to modify documentation to describe reality even if that reality isn't what people want to hear, I have checked in a fix so that your unique (I have never known anyone want to do what you want) situation is handled consistently between gr2 and gr1. Now you can go and solve your problem in lots of different ways. Yours, Martin |
From: Sharon C. <sha...@si...> - 2012-07-28 20:24:56
|
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. |
From: Shriramana S. <sa...@gm...> - 2012-07-28 17:08:58
|
On Sat, Jul 28, 2012 at 12:36 AM, Sharon Correll <sha...@si...> wrote: > In the original Graphite engine, side-by-side attachments are supposed > to preserve the order of the glyphs. So I expect/hope what you're > seeing is in Graphite2. Yes as I said it is the behaviour seen in LibO. In XeTeX (see https://sites.google.com/site/jamadagni/files/temp/krishna-tamil-reordered-attachment-test-1.zip), attaching ை to க does not cause the reordering. This all the more strengthens my contention that Gr2 should not change the positioning of glyphs when in-place attachment is requested. (Is http://hg.palaso.org/graphitedev/rev/ad1e222b3b16 supposed to address my complaint since its comment reads "Fix ordered attachment defaults"?) 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? In my Krishna Tamil font's current devel version (available at https://bugs.freedesktop.org/attachment.cgi?id=64767) I attach chandrabindu-s to base characters, and the chandrabindu glyph in the font actually has an advancewidth of 526 but after attachment I don't see any corresponding shifting of the next glyph. This behaviour *seems* correct and appropriate, as it allows me to set a non-zero advancewidth to "automatically" make my diacritic a spacing character if a suitable base for attachment is not found (so that it will not overlap with any succeeding duplicate glyphs). So this behaviour is appropriate, then it seems that (see in the Google Sites zip file linked above) XeTeX has not at all processed the second level diacritic, since it is shown with a positive advancewidth. But if you people are not maintaining Gr1 anymore, I had better just strengthen my prayers for XeTeX to be ported to HB/Gr2. -- Shriramana Sharma |
From: Carsten B. <ca...@gm...> - 2012-07-28 10:24:42
|
On 27.07.2012 20:46, Sharon Correll wrote: > If you use the -D option (if -D doesn't work try -d) on the compiler, it > will output a set of debugger files including one called > dbg_ruleprec.txt that shows the complete set of rules (taking optional > items into account) in precedence order. Ah, nice. >If you pick a simple example and tell me exactly which > rules you expect to fire, I can probably help. Fortunately, I could already help myself by playing around a bit and peeking from Shriramana's GDL file after I sent my mail. The problem was how to stack diacritics on diacrtics, but I've generalized my rules (a group for all top diacritics, and another for all bottom diacritics) and divided them into passes now, so that in the first pass, any diacritic is placed over/below a consonant matrice, and then in a second pass, diacritics can be attached to the syllable block from the first pass. The GDL snippets from the Graphite page were helpful, too. If anyone is interested, I've uploaded the current working draft again, at <http://dl.dropbox.com/u/8026017/tagbkrg-dev_snapshot_2012-07-28.zip> Regards C. Becker |