You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(28) |
Dec
(50) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(143) |
Feb
(48) |
Mar
(27) |
Apr
(22) |
May
(20) |
Jun
(45) |
Jul
(117) |
Aug
(108) |
Sep
(55) |
Oct
(41) |
Nov
(46) |
Dec
(25) |
2004 |
Jan
(20) |
Feb
(42) |
Mar
(29) |
Apr
(16) |
May
(38) |
Jun
(21) |
Jul
(5) |
Aug
(23) |
Sep
(26) |
Oct
(62) |
Nov
(25) |
Dec
(109) |
2005 |
Jan
(26) |
Feb
(44) |
Mar
(17) |
Apr
(4) |
May
(24) |
Jun
(10) |
Jul
|
Aug
(35) |
Sep
(60) |
Oct
(49) |
Nov
(30) |
Dec
(58) |
2006 |
Jan
(58) |
Feb
(25) |
Mar
(57) |
Apr
(14) |
May
(4) |
Jun
|
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(8) |
Nov
(12) |
Dec
(20) |
2007 |
Jan
(7) |
Feb
(27) |
Mar
(85) |
Apr
(51) |
May
(45) |
Jun
(21) |
Jul
(54) |
Aug
(34) |
Sep
(13) |
Oct
(19) |
Nov
(20) |
Dec
|
2008 |
Jan
(78) |
Feb
(44) |
Mar
(17) |
Apr
(3) |
May
(19) |
Jun
(2) |
Jul
(8) |
Aug
(15) |
Sep
(13) |
Oct
(10) |
Nov
(1) |
Dec
(3) |
2009 |
Jan
|
Feb
(11) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(8) |
Jul
(20) |
Aug
(26) |
Sep
(2) |
Oct
(8) |
Nov
(2) |
Dec
|
2010 |
Jan
(18) |
Feb
|
Mar
(1) |
Apr
(49) |
May
(20) |
Jun
(12) |
Jul
(5) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
2011 |
Jan
(3) |
Feb
(4) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(7) |
Jul
(30) |
Aug
(17) |
Sep
(26) |
Oct
(15) |
Nov
|
Dec
(4) |
2012 |
Jan
(3) |
Feb
(15) |
Mar
(20) |
Apr
(5) |
May
(1) |
Jun
(42) |
Jul
(11) |
Aug
(10) |
Sep
(12) |
Oct
|
Nov
(5) |
Dec
|
2013 |
Jan
(6) |
Feb
(2) |
Mar
(2) |
Apr
(3) |
May
(4) |
Jun
(6) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
(6) |
Dec
|
2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2016 |
Jan
(17) |
Feb
(3) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Martin H. <mar...@si...> - 2013-05-24 16:23:28
|
Dear Shriramana, > I'd like to know what's with the windows.h thing. Why was it necessary and > I hope it need not concern me who am on Linux. It won't affect linux builds for obvious reasons (windows.h doesn't get used on linux). The reason is to do with mingw builds. Basically, while the filename is one, everyone uses the wrong name and it gets sorted out. We were doing the right thing and it was causing problems. In short, this should make things better not worse and it's what all other projects of this kind do, so we are merely following the crowd. Yours, Martin |
From: Shriramana S. <sa...@gm...> - 2013-05-24 16:12:19
|
Hello Martin and thanks for this update. I'd like to know what's with the windows.h thing. Why was it necessary and I hope it need not concern me who am on Linux. Sent from my Android phone |
From: Martin H. <mar...@si...> - 2013-05-24 13:49:37
|
Dear All, Announcing a new release of Graphite2, downloadable from the normal culprits: http://projects.palaso.org/attachments/download/378/graphite2-1.2.2.tgz http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.2.2.tgz/download Here is the relevant section of the Changelog: . Add support for passKeySlot (makes Charis 2x faster) up to 32 passes . Add telemetry output to json if enabled in build GRAPHITE2_TELEMETRY . Shrink font memory footprint particularly in the fsm . Add -S to comparerenderer . Bug fixes: . Fix shift.x being reversed for rtl text . Fix faulty fallback justification . Fix bad cmap handling . Support compiling on old Solaris where bidi attributes clash with register names . Follow the crowd in using Windows.h The most exciting of these is the first where we have made a change to the compiler that means that a suitably compiled font has an attribute that for each pass has a bit. If the bit is set, then this particular glyph does not force the pass to be run. Thus if all the glyphs in a run do not require a pass to be run, the pass can and is skipped. This can radically speed up things like pure lowerascii shaping. A key bug fix is that shift.x was working the wrong way round in rtl fonts. This has been fixed in this release. Yours, Martin |
From: Martin H. <mar...@si...> - 2013-04-30 19:56:46
|
Dear Roland, > I.e. instead of "0.0", we get "-0.0", i.e. "another zero". ;-) Any library that prints out -0.0 has something wrong with it, surely? I suppose it could be getting something like -0.0001 out of the maths somewhere :( > In the former case, can we make the test script tolerate "-0.0" instead > of "0.0"? I'd be happy to provide a patch - just want to know in which > direction we should go. I would prefer it if you could find a way to get gr2fonttest not to output -0.0 first. If you can't do that then go for a suitable comparator, but that's second best. And yes we are open to accepting patches to fix these kinds of things. Yours, Martin |
From: Roland S. <st...@an...> - 2013-04-29 20:16:39
|
Hi, I'm currently porting graphite2 to the PowerPC SPE architecture[1][2] (aka e500v2). On "make && make test", the following happens: ========================================================================= [...] Start 35: scher1 35/99 Test #35: scher1 ........................... Passed 0.03 sec Start 36: scher1Output 36/99 Test #36: scher1Output .....................***Failed 0.02 sec [...] 99% tests passed, 1 tests failed out of 99 Total Test time (real) = 13.04 sec The following tests FAILED: 36 - scher1Output (Failed) Errors while running CTest make: *** [test] Error 8 ========================================================================= The difference between the expected and actual output is: ========================================================================= $ diff -u ./tests/standards/scher1.log ./build/tests/scher1.log --- ./tests/standards/scher1.log 2013-02-27 19:32:04.000000000 +0000 +++ ./build/tests/scher1.log 2013-04-28 21:01:50.940395336 +0000 @@ -9,7 +9,7 @@ 04 971 3@220,1035 3.9 0.1 1 30 5 5 654 654 05 965 4@100,1330 3.8 1.9 1 30 4 4 64e 64e 06 1233 3@150,250 0.4 0.0 1 30 6 6 627 627 -07 965 6@47,949 0.0 -0.4 1 30 7 7 64e 64e +07 965 6@47,949 -0.0 -0.4 1 30 7 7 64e 64e Advance width = 10.7 Char Unicode Before After ========================================================================= I.e. instead of "0.0", we get "-0.0", i.e. "another zero". ;-) The output is formatted in gr2fonttest/gr2FontTest.cpp:726 via fprintf()'s "%6.1f" from "float orgX". So I'm wondering if this "other zero" value -0.0 is precise enough, i.e. rounding s.th. like -0.00xxx towards 0 is fine or if we should really expect a value strictly > 0 here. In the former case, can we make the test script tolerate "-0.0" instead of "0.0"? I'd be happy to provide a patch - just want to know in which direction we should go. (All the other tests run fine on PowerPC SPE.) Thanks in advance, Roland [1] http://wiki.debian.org/PowerPCSPEPort [2] http://en.wikipedia.org/wiki/PowerPC_e500 |
From: SourceForge.net <no...@so...> - 2013-04-11 13:29:05
|
Patches item #3609008, was opened at 2013-03-25 06:09 Message generated for change (Comment added) made by mhosken You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=513481&aid=3609008&group_id=66144 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Apostolos Syropoulos (asyropoulos) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot compile graphit2 on Solaris Initial Comment: I have tried to compile graphite2 on Solaris x86 and it failed. The reason is that two symbols defined in Bidi.cpp are already taken by the OS, IN particular, /usr/include/sys/regset.h sets #define ES 2 ..... #define CS 15 which are also used in Bidi.cpp So I am proposing to change the names of these symbols. ---------------------------------------------------------------------- >Comment By: Martin Hosken (mhosken) Date: 2013-04-11 06:29 Message: Already fixed in trunk. Will appear in next release or take a copy from the repo now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=513481&aid=3609008&group_id=66144 |
From: SourceForge.net <no...@so...> - 2013-03-25 13:09:56
|
Patches item #3609008, was opened at 2013-03-25 06:09 Message generated for change (Tracker Item Submitted) made by asyropoulos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=513481&aid=3609008&group_id=66144 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Apostolos Syropoulos (asyropoulos) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot compile graphit2 on Solaris Initial Comment: I have tried to compile graphite2 on Solaris x86 and it failed. The reason is that two symbols defined in Bidi.cpp are already taken by the OS, IN particular, /usr/include/sys/regset.h sets #define ES 2 ..... #define CS 15 which are also used in Bidi.cpp So I am proposing to change the names of these symbols. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=513481&aid=3609008&group_id=66144 |
From: Martin H. <mar...@si...> - 2013-03-01 18:49:36
|
Dear All, Announcing the release of the graphite2 engine latest release of 1.2.1. The main thing here is bug fixes which are well worth back porting. It is available from the usual places: http://projects.palaso.org/attachments/download/361/graphite2-1.2.1.tgz http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.2.1.tgz/download This from the changelog: 1.2.1 . Bug fixes: . Allow glyph reattachment . Allow signed glyph attributes . Various build problems with MacOS, old gcc versions, etc. . Various overrun read errors fixed Yours, Martin |
From: Sharon C. <sha...@si...> - 2013-02-14 15:39:28
|
Yes, it is the default behavior of the font when the user didn't specify anything. On 2/13/2013 4:34 PM, Khaled Hosny wrote: > I'm starting to think that I had a big misunderstanding on what > "default" in GDL feature definition means, I thought it mean the default > setting of the feature when user activates it, but now I'm starting to > think it means the default behaviour of the font if the user did not > explicitly enable that feature, if my later understanding is true then > this explains a lot and gr_face_featureval_for_lang() would be indeed > what I was looking for. > > Regards, > Khaled |
From: Khaled H. <kha...@eg...> - 2013-02-13 23:34:38
|
On Mon, Jan 14, 2013 at 11:03:43AM +0000, Martin Hosken wrote: > On Sat, 12 Jan 2013 19:27:48 +0200 > Khaled Hosny <kha...@eg...> wrote: > > > On Sat, Jan 12, 2013 at 04:34:14PM +0000, Martin Hosken wrote: > > > > > > Dear Khaled, > > > > > > > I don’t seem to find the Graphite2 API for finding the default setting > > > > of a value, did I miss something or no such API is avialable, and, if > > > > yes, why? > > > > > > Can you tell me a bit more about which value you are wanting to query of what object? > > > > I’m trying to find the default setting for any given feature (i.e. the > > .default member of the feature in GDL), for two uses: XeTeX has a > > primitive that tells if a given feature setting is the default or not, > > and to find which setting to use when user specifies a feature with no > > value, e.g.: > > > > \font\foo="Foo/Gr:Alternate Shape" > > > > as opposed to: > > > > \font\foo="Foo/Gr:Alternate Shape=1" > > > > You are correct in saying that there is no direct API to give you your > answer. But there is a pretty easy workaround. > > The first question you have to answer is whether you want your default > to be a language independent default or whether what you want is a > language tuned default. If someone sets the language attribute, do you > want that to set give the default or do you want the default to ignore > that language attribute? The XeTeX primitives affected by this query the font as defined by the user, so the language dependence depends on whether the user defined the font with a language or not i.e. what XeTeX should report is the behaviour that the font as defined by the user would exhibit. > The Graphite API allows you to create a feature value which holds all > the values for all the features in a font > (gr_face_featureval_for_lang). You can create one based on no language > or on a particular language. You can then query this using a feature > ref to find the default value for that feature > (gr_fref_feature_value). > > Does that scratch the itch? I'm starting to think that I had a big misunderstanding on what "default" in GDL feature definition means, I thought it mean the default setting of the feature when user activates it, but now I'm starting to think it means the default behaviour of the font if the user did not explicitly enable that feature, if my later understanding is true then this explains a lot and gr_face_featureval_for_lang() would be indeed what I was looking for. Regards, Khaled |
From: Martin H. <mar...@si...> - 2013-01-14 11:04:00
|
On Sat, 12 Jan 2013 19:27:48 +0200 Khaled Hosny <kha...@eg...> wrote: > On Sat, Jan 12, 2013 at 04:34:14PM +0000, Martin Hosken wrote: > > > > Dear Khaled, > > > > > I don’t seem to find the Graphite2 API for finding the default setting > > > of a value, did I miss something or no such API is avialable, and, if > > > yes, why? > > > > Can you tell me a bit more about which value you are wanting to query of what object? > > I’m trying to find the default setting for any given feature (i.e. the > .default member of the feature in GDL), for two uses: XeTeX has a > primitive that tells if a given feature setting is the default or not, > and to find which setting to use when user specifies a feature with no > value, e.g.: > > \font\foo="Foo/Gr:Alternate Shape" > > as opposed to: > > \font\foo="Foo/Gr:Alternate Shape=1" > You are correct in saying that there is no direct API to give you your answer. But there is a pretty easy workaround. The first question you have to answer is whether you want your default to be a language independent default or whether what you want is a language tuned default. If someone sets the language attribute, do you want that to set give the default or do you want the default to ignore that language attribute? The Graphite API allows you to create a feature value which holds all the values for all the features in a font (gr_face_featureval_for_lang). You can create one based on no language or on a particular language. You can then query this using a feature ref to find the default value for that feature (gr_fref_feature_value). Does that scratch the itch? Yours, Martin > Regards > Khaled > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_123012 > _______________________________________________ > Silgraphite-devel mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-devel |
From: Khaled H. <kha...@eg...> - 2013-01-12 17:28:16
|
On Sat, Jan 12, 2013 at 04:34:14PM +0000, Martin Hosken wrote: > > Dear Khaled, > > > I don’t seem to find the Graphite2 API for finding the default setting > > of a value, did I miss something or no such API is avialable, and, if > > yes, why? > > Can you tell me a bit more about which value you are wanting to query of what object? I’m trying to find the default setting for any given feature (i.e. the .default member of the feature in GDL), for two uses: XeTeX has a primitive that tells if a given feature setting is the default or not, and to find which setting to use when user specifies a feature with no value, e.g.: \font\foo="Foo/Gr:Alternate Shape" as opposed to: \font\foo="Foo/Gr:Alternate Shape=1" Regards Khaled |
From: Martin H. <mar...@si...> - 2013-01-12 16:33:43
|
Dear Khaled, > I don’t seem to find the Graphite2 API for finding the default setting > of a value, did I miss something or no such API is avialable, and, if > yes, why? Can you tell me a bit more about which value you are wanting to query of what object? TIA, Yours, Martin > > Regards, > Khaled > > P.S. I’m not subscribed to the list, so please CC me in your replies. > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122912 > _______________________________________________ > Silgraphite-devel mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-devel |
From: Khaled H. <kha...@eg...> - 2013-01-08 16:01:29
|
Hi all, I don’t seem to find the Graphite2 API for finding the default setting of a value, did I miss something or no such API is avialable, and, if yes, why? Regards, Khaled P.S. I’m not subscribed to the list, so please CC me in your replies. |
From: Sharon C. <sha...@si...> - 2013-01-07 15:16:51
|
I'm not sure it's worth changing the old Graphite engine. (I hate the idea, at any rate!) But possibly Graphite2 should handle this new stuff. At any rate, I probably ought to read it and try to get my head around it. Thanks for the heads up. On 1/3/2013 10:24 PM, Bob Hallissy wrote: > Is anyone evaluating the impact of this on the Graphite engines? > Bob > > -------- Original Message -------- > Subject: Major changes to Unicode for Arabic & Hebrew > Date: Thu, 03 Jan 2013 15:01:57 -0800 > From: ann...@un... > Reply-To: ro...@un... > To: ann...@un... > > > > UAX #9, Unicode Bidirectional Algorithm, will be updated for Unicode > 6.3. The Unicode BIDI algorithm is used for displaying all Arabic and > Hebrew text on the web and in application programs, so any changes > require careful review. > > This proposed update involves a substantial extension of the Unicode > Bidirectional Algorithm to allow for the implementation of isolate runs. > It also introduces new Bidi_Class property values and formatting > characters in support of that extension. > > There are also changes to Section 3.3.4 Resolving Neutral Types to > resolve paired punctuation marks as a unit. This adds a new rule N0. > > See the modifications section of the proposed update for information on > specific changes to sections in the document. > > The proposed update is available here: > http://www.unicode.org/reports/tr9/tr9-28.html > > > http://unicode-inc.blogspot.com/2013/01/major-changes-to-unicode-for-arabic.html > |
From: Bob H. <Bob...@si...> - 2013-01-04 04:38:51
|
Is anyone evaluating the impact of this on the Graphite engines? Bob -------- Original Message -------- Subject: Major changes to Unicode for Arabic & Hebrew Date: Thu, 03 Jan 2013 15:01:57 -0800 From: ann...@un... Reply-To: ro...@un... To: ann...@un... UAX #9, Unicode Bidirectional Algorithm, will be updated for Unicode 6.3. The Unicode BIDI algorithm is used for displaying all Arabic and Hebrew text on the web and in application programs, so any changes require careful review. This proposed update involves a substantial extension of the Unicode Bidirectional Algorithm to allow for the implementation of isolate runs. It also introduces new Bidi_Class property values and formatting characters in support of that extension. There are also changes to Section 3.3.4 Resolving Neutral Types to resolve paired punctuation marks as a unit. This adds a new rule N0. See the modifications section of the proposed update for information on specific changes to sections in the document. The proposed update is available here: http://www.unicode.org/reports/tr9/tr9-28.html http://unicode-inc.blogspot.com/2013/01/major-changes-to-unicode-for-arabic.html ---- |
From: Martin H. <mar...@si...> - 2012-11-21 09:01:14
|
Dear Sharon, > So you're saying that we would create 16 built-in slot attributes > called ref1, ref2, ref3, whose values are expected to be a slot > reference. (I assume these could be #defined to have more meaningful > names just like user1, user2, etc.) > > This seems fairly easy at the compiler level. I must be missing > something. :-) :) Yes it's that simple, at the syntax level. > Do the values need to be computed (eg, @user1+someglyphattr), or will > they always be simple integers (@1, @2, etc)? No the values don't need to be computed, but notice that we need a special opcode to get from a slot-ref to a slot pointer in the engine. > > Anyway my proposal is to add a slot attribute class .ref as in: > > > > cBase cAttach { ref1=@1 }; > > > > I think I won't need more than 16 of these. > > > > In opcode terms we are thinking the best thing is to have a separate stack onto which pointers to slot are put. > > Is this what you are calling the "slot stack"? Yes. > > PushSlot slot_ref : finds the point to the given slot and push it onto the slot stack > > I assume you mean the pointer... typo: finds the pointer to the given slot. So yes. > > > SetISlotRefAttr slot_ref index : pops the slot stack and stores in the given slots given slot reference attribute > > GetISlotRefAttr slot_ref index : gets the slot reference attribute from the referenced slot and pushes it onto the slot stack. > > > > The immediate thought is that all opcodes involving a slot_ref are now going to need slot stack based versions. But an alternative is to say that a slot_ref = 0x7F would mark that the slot_ref is to come from the slot stack rather than as an index into the slot array. This works because rules can't be longer than 64 slots long anyway so you shouldn't be up that high. > > I don't understand this. Are you saying that AttrSetSlot and > IAttrSetSlot need to be able to pop from the new slot stack as well as > the standard stack (in order to set slot-ref slot attributes on the > current slot)? But if so, how does the 0x7F play in, where does it go? > Or does this refer to PushAttToGlyphAttr and PushAttToGlyphMetric? > (but I'm not clear why that would be needed). Sorry, yes it's PushISlotAttr, PushGlyphAttr, PushGlyphMetric. I.e. wherever a slot-offset is used (which is always a parameter and never on the stack), you can use a slot-offset of 0x7F and the opcode will use the current top of slot stack as the slot to use instead of that referenced by the slot-offset. > Isn't the whole purpose of a stack to handle arbitrarily > complex/nested arithmetic operations? So if there is no arithmetic > being done on a slot-reference value, why have a stack at all? Why not > just 16 "registers"? Is that what you're suggesting? Or is arithmetic > in fact needed to calculate the index of the slot? The reason for a separate stack is so that you can copy values from one slot to another explicitly. Thus to do the type of referencing I think I'm going to need I will do something mad like: c_base c_base{ref1 = @1; ref2=@1.ref1; ref3=@1.ref2; ref4=@1.ref3; ...} / _ [long context] _; This is the only real use case I can see for having a slot stack. If you can find a natural, safe, low cost way of achieving the same thing. I'm very open to an alternative implementation approach. > (And what is a non-popping stack, anyway? Aren't pushing and popping > inherent in the definition of a stack? :-) ) If you define a stack that way, then it isn't a stack. But I bet if I said it was a log you wouldn't immediately have understood what I was talking about ;) GB, Martin |
From: Sharon C. <sha...@si...> - 2012-11-20 17:16:39
|
So you're saying that we would create 16 built-in slot attributes called ref1, ref2, ref3, whose values are expected to be a slot reference. (I assume these could be #defined to have more meaningful names just like user1, user2, etc.) This seems fairly easy at the compiler level. I must be missing something. :-) Do the values need to be computed (eg, @user1+someglyphattr), or will they always be simple integers (@1, @2, etc)? More questions below... On 11/20/2012 2:23 AM, Martin Hosken wrote: > Dear Sharon, > > In my thinking about signwriting, I am realising that trying to do all of the associating of diacritics to base characters is going to end up in a complete nightmare of regular expressions. But if we could add a feature of being able to store slot references as an attribute (well a set of slot reference attributes) on a slot, then life could become a whole lot simpler. I don't know how interested other scripts would be in this. Perhaps it would save walking backwards through nastaliq text for example. > > Anyway my proposal is to add a slot attribute class .ref as in: > > cBase cAttach { ref1=@1 }; > > I think I won't need more than 16 of these. > > In opcode terms we are thinking the best thing is to have a separate stack onto which pointers to slot are put. Is this what you are calling the "slot stack"? > This stops people doing math on pointers, for example. It also gets around the 32-bit/64-bit problem and the question of storing 64-bit pointers in user attributes which are 16 bit. Using absolute pointers is much easier for GDL authors since they can delete stuff in between and not worry about having to update things. > > This would require a new opcode: > > PushSlot slot_ref : finds the point to the given slot and push it onto the slot stack I assume you mean the pointer... > SetISlotRefAttr slot_ref index : pops the slot stack and stores in the given slots given slot reference attribute > GetISlotRefAttr slot_ref index : gets the slot reference attribute from the referenced slot and pushes it onto the slot stack. > > The immediate thought is that all opcodes involving a slot_ref are now going to need slot stack based versions. But an alternative is to say that a slot_ref = 0x7F would mark that the slot_ref is to come from the slot stack rather than as an index into the slot array. This works because rules can't be longer than 64 slots long anyway so you shouldn't be up that high. I don't understand this. Are you saying that AttrSetSlot and IAttrSetSlot need to be able to pop from the new slot stack as well as the standard stack (in order to set slot-ref slot attributes on the current slot)? But if so, how does the 0x7F play in, where does it go? Or does this refer to PushAttToGlyphAttr and PushAttToGlyphMetric? (but I'm not clear why that would be needed). > While this approach will make doing signwriting possible, it's not completely ideal since I would quite like a non-popping stack of these slot_refs. But I think that is overkill for one script. I can see that having a generalised ability to add slot refs to a slot is going to be useful elsewhere. In addition, it would still be needed even if I had my non-popping stack. So I suppose this is the minimum necessary to make signwriting feasible. Isn't the whole purpose of a stack to handle arbitrarily complex/nested arithmetic operations? So if there is no arithmetic being done on a slot-reference value, why have a stack at all? Why not just 16 "registers"? Is that what you're suggesting? Or is arithmetic in fact needed to calculate the index of the slot? (And what is a non-popping stack, anyway? Aren't pushing and popping inherent in the definition of a stack? :-) ) > What do people think? Would you rush out and use/abuse this feature? If so, what would your use case be? It's not immediately clear how this would be useful in other scripts, but I haven't had time to think about it. |
From: Martin H. <mar...@si...> - 2012-11-20 14:15:56
|
Dear Shriramana, > > Anyway my proposal is to add a slot attribute class .ref as in: > > > > cBase cAttach { ref1=@1 }; > > ... > > What do people think? Would you rush out and use/abuse this feature? If so, what would your use case be? > > Hi Martin. As you can see I cut out all the opcode etc implementation > details which I am not interested in / knowledgeable about. I am only > interested in the functionality. Unfortunately I did not understand > your proposal very well. Could you please give an example of what you > intend to provide and how it would help (which) users? Thanks! imagine in one pass, I want to keep track of a particular glyph so that I can attach to it later: cBase cAttach {ref1 = @1} / _ [lots of complex optional glyphs] _; then when it comes to attachment time in a subsequent pass in the positioning table, I would be able to do: cAttach {attach {to = ref1; with = UM; at = US}}; hmm. the ref1 there may need some refinement syntactically, but you get the idea I hope. If you don't then don't worry too much about it. It's a pretty corner case for most font applications. Yours, Martin |
From: Shriramana S. <sa...@gm...> - 2012-11-20 09:20:15
|
On Tue, Nov 20, 2012 at 1:53 PM, Martin Hosken <mar...@si...> wrote: > In my thinking about signwriting, I am realising that trying to do all of the associating of diacritics to base characters is going to end up in a complete nightmare of regular expressions. But if we could add a feature of being able to store slot references as an attribute (well a set of slot reference attributes) on a slot, then life could become a whole lot simpler. I don't know how interested other scripts would be in this. Perhaps it would save walking backwards through nastaliq text for example. > > Anyway my proposal is to add a slot attribute class .ref as in: > > cBase cAttach { ref1=@1 }; > ... > What do people think? Would you rush out and use/abuse this feature? If so, what would your use case be? Hi Martin. As you can see I cut out all the opcode etc implementation details which I am not interested in / knowledgeable about. I am only interested in the functionality. Unfortunately I did not understand your proposal very well. Could you please give an example of what you intend to provide and how it would help (which) users? Thanks! -- Shriramana Sharma |
From: Martin H. <mar...@si...> - 2012-11-20 08:23:51
|
Dear Sharon, In my thinking about signwriting, I am realising that trying to do all of the associating of diacritics to base characters is going to end up in a complete nightmare of regular expressions. But if we could add a feature of being able to store slot references as an attribute (well a set of slot reference attributes) on a slot, then life could become a whole lot simpler. I don't know how interested other scripts would be in this. Perhaps it would save walking backwards through nastaliq text for example. Anyway my proposal is to add a slot attribute class .ref as in: cBase cAttach { ref1=@1 }; I think I won't need more than 16 of these. In opcode terms we are thinking the best thing is to have a separate stack onto which pointers to slot are put. This stops people doing math on pointers, for example. It also gets around the 32-bit/64-bit problem and the question of storing 64-bit pointers in user attributes which are 16 bit. Using absolute pointers is much easier for GDL authors since they can delete stuff in between and not worry about having to update things. This would require a new opcode: PushSlot slot_ref : finds the point to the given slot and push it onto the slot stack SetISlotRefAttr slot_ref index : pops the slot stack and stores in the given slots given slot reference attribute GetISlotRefAttr slot_ref index : gets the slot reference attribute from the referenced slot and pushes it onto the slot stack. The immediate thought is that all opcodes involving a slot_ref are now going to need slot stack based versions. But an alternative is to say that a slot_ref = 0x7F would mark that the slot_ref is to come from the slot stack rather than as an index into the slot array. This works because rules can't be longer than 64 slots long anyway so you shouldn't be up that high. While this approach will make doing signwriting possible, it's not completely ideal since I would quite like a non-popping stack of these slot_refs. But I think that is overkill for one script. I can see that having a generalised ability to add slot refs to a slot is going to be useful elsewhere. In addition, it would still be needed even if I had my non-popping stack. So I suppose this is the minimum necessary to make signwriting feasible. What do people think? Would you rush out and use/abuse this feature? If so, what would your use case be? Yours, Martin |
From: Martin H. <mar...@si...> - 2012-09-21 08:52:47
|
Dear All, A new version of the graphite engine has been released. This version has added functions to the API that are aimed at simplifying life for integrators. But it still remains almost entirely (sans the debug logging interface) source compatible with v1.1.x. The source is available from the usual suspects: http://projects.palaso.org/attachments/download/298/graphite2-1.2.0.tgz http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.2.0.tgz/download Here is the changelog for this release: . API Changes: . Added Windows friendly gr_start_logging and gr_stop_logging, now per face . Added gr_make_face_with_ops, gr_make_face_with_seg_cache_and_ops . Added gr_make_font_with_ops . Added gr_face_is_char_supported . Added gr_face_info to give info to apps about face capabilities . Deprecated gr_make_face, gr_make_face_with_seg_cache, gr_make_font_with_advance_fn . Deprecated graphite_start_logging and graphite_stop_logging . These functions are stubbed now and do nothing, but do compile and link. . Bump API version to 3 . Add C# wrapper to contrib . Handle justification information in a font and do something useful with it . Builds clang clean (has done for a while) . Bug fixes . Windows build and bug fixes . Add extra information to json debug output . Added windows build documentation . Added freetype sample code and test GB, Martin |
From: Sharon C. <sha...@si...> - 2012-09-10 22:44:44
|
Done. On 9/10/2012 5:34 PM, Sharon Correll wrote: > Yes, I could add that information. > > On 9/10/2012 1:46 PM, Bob Hallissy wrote: >> The Applications that support Graphite >> <http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_apps> >> page is a helpful resource, but... >> >> does anyone have enough data to indicate which engine (Graphite 1 >> or 2) is used in each application? >> >> (one would hope it doesn't matter, but practically speaking it does >> matter as things aren't quite the same.) >> >> Bob >> >> >> ------------------------------------------------------------------------------ >> 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-devel mailing list >> Sil...@li... >> https://lists.sourceforge.net/lists/listinfo/silgraphite-devel > > > > ------------------------------------------------------------------------------ > 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-devel mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-devel |
From: Sharon C. <sha...@si...> - 2012-09-10 22:34:43
|
Yes, I could add that information. On 9/10/2012 1:46 PM, Bob Hallissy wrote: > The Applications that support Graphite > <http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_apps> > page is a helpful resource, but... > > does anyone have enough data to indicate which engine (Graphite 1 or > 2) is used in each application? > > (one would hope it doesn't matter, but practically speaking it does > matter as things aren't quite the same.) > > Bob > > > ------------------------------------------------------------------------------ > 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-devel mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-devel |
From: Bob H. <Bob...@si...> - 2012-09-10 18:46:47
|
The Applications that support Graphite <http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_apps> page is a helpful resource, but... does anyone have enough data to indicate which engine (Graphite 1 or 2) is used in each application? (one would hope it doesn't matter, but practically speaking it does matter as things aren't quite the same.) Bob |