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...> - 2012-09-05 02:01:31
|
On Tue, 04 Sep 2012 11:35:06 -0600 Neil Mayhew <nei...@si...> wrote: > On 2012-09-03 7:36 PM Martin Hosken wrote: > > Graphite2 has a C interface. Download graphite2 (the preferred engine now) > > What if the main application is using the older graphite library? > Presumably both libraries will report the same features, but there will > be two different libraries loaded into the same process. Hopefully there > won't be any symbol conflicts. I don't see why there should be any conflicts. And both are well behaved apis that aren't going to stomp on each other. > Tom's main application is using graphite through firefox/gecko. Which > graphite library is Firefox using nowadays? As Sharon said. Gr2. GB, Martin |
From: Sharon C. <sha...@si...> - 2012-09-04 17:57:47
|
Firefox uses Graphite2. On 9/4/2012 12:35 PM, Neil Mayhew wrote: > Tom's main application is using graphite through firefox/gecko. Which > graphite library is Firefox using nowadays? |
From: Neil M. <nei...@si...> - 2012-09-04 17:35:19
|
On 2012-09-03 7:36 PM Martin Hosken wrote: > Graphite2 has a C interface. Download graphite2 (the preferred engine now) What if the main application is using the older graphite library? Presumably both libraries will report the same features, but there will be two different libraries loaded into the same process. Hopefully there won't be any symbol conflicts. Tom's main application is using graphite through firefox/gecko. Which graphite library is Firefox using nowadays? --Neil |
From: Shriramana S. <sa...@gm...> - 2012-09-04 08:53:32
|
I was looking under the graphitedev but didn't get it, then had a hunch and searched and found it at graide/lib/graide/graphite.py. Couldn't you include this with libgr2 though? -- Shriramana Sharma |
From: Shriramana S. <sa...@gm...> - 2012-09-04 07:09:29
|
Hi Martin, where can I get the Python bindings? I don't seem to have anything for Python in my palaso hg clone. Sent from my Android phone On Sep 4, 2012 7:06 AM, "Martin Hosken" <mar...@si...> wrote: > Dear Tom, > > > I looking at querying a fonts features tables from C#. > > > > I thought about directly invoking [lib]graphite.(so|dll) from C# but > > rejected that idea due to graphite a lack of C api. (I don't want to > > maintain a c wrapper lib or use experimental stuff like cxxi) > > Graphite2 has a C interface. Download graphite2 (the preferred engine now) > from > http://projects.palaso.org/attachments/download/242/graphite2-1.1.3.tgzthere is sample code in the tests/examples directory. You can get a pretty > PDF of it all at > http://projects.palaso.org/attachments/download/212/manual.pdf > > It would be great to have a C# wrapper for graphite2. When I did a ctypes > layer for python, it took about half a day. > > GB, > Martin > > > ------------------------------------------------------------------------------ > 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: Tom H. <tom...@si...> - 2012-09-04 03:21:15
|
Hi Martin, On Tue, 4 Sep 2012 08:36:28 +0700 Martin Hosken <mar...@si...> wrote: >Dear Tom, > >> I looking at querying a fonts features tables from C#. >> >> I thought about directly invoking [lib]graphite.(so|dll) from C# but >> rejected that idea due to graphite a lack of C api. (I don't want to >> maintain a c wrapper lib or use experimental stuff like cxxi) > >Graphite2 has a C interface. Download graphite2 (the preferred engine now) from http://projects.palaso.org/attachments/download/242/graphite2-1.1.3.tgz there is sample code in the tests/examples directory. You can get a pretty PDF of it all at http://projects.palaso.org/attachments/download/212/manual.pdf > That's great, thank you! >It would be great to have a C# wrapper for graphite2. When I did a ctypes layer for python, it took about half a day. I will give that a go... Thanks Tom > >GB, >Martin > >------------------------------------------------------------------------------ >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: Martin H. <mar...@si...> - 2012-09-04 01:36:47
|
Dear Tom, > I looking at querying a fonts features tables from C#. > > I thought about directly invoking [lib]graphite.(so|dll) from C# but > rejected that idea due to graphite a lack of C api. (I don't want to > maintain a c wrapper lib or use experimental stuff like cxxi) Graphite2 has a C interface. Download graphite2 (the preferred engine now) from http://projects.palaso.org/attachments/download/242/graphite2-1.1.3.tgz there is sample code in the tests/examples directory. You can get a pretty PDF of it all at http://projects.palaso.org/attachments/download/212/manual.pdf It would be great to have a C# wrapper for graphite2. When I did a ctypes layer for python, it took about half a day. GB, Martin |
From: Tom H. <tom...@si...> - 2012-09-03 17:04:18
|
Hi, I looking at querying a fonts features tables from C#. I thought about directly invoking [lib]graphite.(so|dll) from C# but rejected that idea due to graphite a lack of C api. (I don't want to maintain a c wrapper lib or use experimental stuff like cxxi) So I plan just to query the feat table using C# by making calls to freetype directly (and relevant win32 apis on windows). I've used the graphite implementation as model for my quick tests. But before I implement it for real, does anyone know of a better easier way of querying a fonts feat table? Thanks Tom |
From: Sharon C. <sha...@si...> - 2012-08-24 20:34:24
|
[After several conversations, I realize I didn't explain the problem very well below. Let me try again: in Graphite1, the special case that happens when advance-width = 0 on combining marks has only been applied to /advance /of the cluster, not the /origin /of the cluster.* More precisely it would only affect the right side, not the left side. This is true even in a RTL font--it would affect the right side, not the left side, because advance is always defined as the width from left to right.] BUT...I realized this will only happen when the glyph origin is at or near the left edge of the bounding box--that's when guard space will show up. Often, combining marks are treated as overstriking, which means that the advance width and origin are both zero, but the bounding box is way out to the left (in negative numbers). The infelicity/bug does not affect these cases, nor will it matter which fix we do. (This is the case with SIL's Roman fonts.) So I am more inclined to fix it "right", especially since this is the way Graphite2 works. If you know of a font that has combining marks where both (a) advance width = 0, and (b) and origin is near the left side of the bounding box--please speak up, or plan to fix the collisions in your font! :-) *My faulty reasoning when I originally implemented this was: the /advance /width on the combining mark should only affect the /advance /of the cluster, not the origin. On 8/22/2012 5:03 PM, Sharon Correll wrote: > [Sorry for cross-posting--this is really a development question, but > I need input from people who know about the Graphite fonts in > existence.] > > There has been an "infelicity" in the Graphite1 (SilGraphite) > engine, which has suddenly become a bug, and I need some input on > how to fix it. > > In normal cases, when you attach one glyph to another, Graphite will > add guard space, that is, adjust the position and advance width of > the base glyph to account for the attached glyphs and their advance > widths. The exception is: if the advance width of the attached glyph > (eg, diacritic or combining mark) is exactly 0, then this will not > be done. > > The "infelicity" was that the special test for advance-width = 0 was > only being applied to the advance of the base (ie, how the right > side of the glyph looks), not for the position of the left side of > the base. I recently realized this is wrong, but I have been > hesitant to change it because I didn't want to break existing fonts. > > Now I realize that the "infelicity" is actually a bug for RTL fonts. > In RTL fonts, the left side of the glyph actually is positioned > using the advance width. So taking into account attached glyphs > creates guard space in the advance width when it is not wanted. > Guard space is bad in cursive scripts--you almost never want it. > > I could fix the bug "correctly", which could possibly have the > effect of breaking existing fonts. Those that would be affected > would be those with combining marks that overhang on the left-hand > side and have been counting on the guard space that is created. > > Or I could fix the bug specifically for the RTL case, so it at least > won't affect LTR fonts. |
From: Rene E. <re...@de...> - 2012-08-23 09:42:09
|
Hi, On Thu, Aug 23, 2012 at 03:48:08PM +0700, Martin Hosken wrote: > > > On Wed, Aug 22, 2012 at 04:18:07PM +0700, Martin Hosken wrote: > > > > The next version of the graphite engine (1.2.0) will have some new API functions added and some deprecated. As a result we need to increase the interface number and we can also increase the age (since we aren't changing or deleting any functions). > > > > > > Forgive me, but what ends up as/in the SONAME as of those? > > > > > > > Thus we are going from 2.0.0 to 3.0.1 (this is separate from the release numbering scheme). > > > > > > Ah, so this will be -3.0.1 as SONAME then. Bad. > > Having dug a bit and found out what we did wrong with the libgraphite2.so.2.0.0, I'm expecting the SONAME to be libgraphite2.so.3 and not have the other bits in the name (i.e. it won't be libgraphite2.so.3.0.1). The library file will be libgraphite2.so.3.0.1. And everything will be as expected. Yeah, that's perfectly fine. I'd agree on that as it then "goes correct" :) > To some extent it's up to you as packager whether you want to put in a lintian override on this, to allow package names that don't include interface numbers, or not. Yeah. > I think the age strategy may possibly be handled in packaging by: making libgraphite2-3 obsolete libgraphite2-2.0.0 and also provide libgraphite2-2.0.0 and then have the package copy the libgraphite2.so.3 link as libgraphite2.so.2.0.0, thus we would end up with something like: > > libgraphite2.so.3.0.1 > libgraphite2.so.3 -> libgraphite2.so.3.0.1 > libgraphite2.so -> libgraphite2.so.3 > libgraphite2.so.2.0.0 -> libgraphite2.so.3.0.1 > > I'm assuming this is more easily handled in packaging than in cmake, but if you want us to do it in the cmake, we can. Nah, can handle it in packaging.. Either by doing as above and keeping -2.0.0 or renaming the package. (it's going better from -2.0.0 anyway) If you *WANT* to handle it in cmake, I won't stop you, though. :) Regards, Rene |
From: Martin H. <mar...@si...> - 2012-08-23 08:48:24
|
Dear Rene, > > On Wed, Aug 22, 2012 at 04:18:07PM +0700, Martin Hosken wrote: > > > The next version of the graphite engine (1.2.0) will have some new API functions added and some deprecated. As a result we need to increase the interface number and we can also increase the age (since we aren't changing or deleting any functions). > > > > Forgive me, but what ends up as/in the SONAME as of those? > > > > > Thus we are going from 2.0.0 to 3.0.1 (this is separate from the release numbering scheme). > > > > Ah, so this will be -3.0.1 as SONAME then. Bad. Having dug a bit and found out what we did wrong with the libgraphite2.so.2.0.0, I'm expecting the SONAME to be libgraphite2.so.3 and not have the other bits in the name (i.e. it won't be libgraphite2.so.3.0.1). The library file will be libgraphite2.so.3.0.1. And everything will be as expected. To some extent it's up to you as packager whether you want to put in a lintian override on this, to allow package names that don't include interface numbers, or not. When we remove the deprecated functions then the interface number will need to bump again (although I am reluctant to cause an API bump just to remove functions, unless we have no choice) to 4.0.0 and so on. I'm not expecting us to remove anything deprecated within a year. Anyway I think we have sorted out the SONAME problem even if it isn't as quiet as you might like. I think the age strategy may possibly be handled in packaging by: making libgraphite2-3 obsolete libgraphite2-2.0.0 and also provide libgraphite2-2.0.0 and then have the package copy the libgraphite2.so.3 link as libgraphite2.so.2.0.0, thus we would end up with something like: libgraphite2.so.3.0.1 libgraphite2.so.3 -> libgraphite2.so.3.0.1 libgraphite2.so -> libgraphite2.so.3 libgraphite2.so.2.0.0 -> libgraphite2.so.3.0.1 I'm assuming this is more easily handled in packaging than in cmake, but if you want us to do it in the cmake, we can. Despite my attempts at possible solutions, it's you doing the packaging and getting the final say on that :) Yours, Martin |
From: Martin H. <mar...@si...> - 2012-08-23 01:56:21
|
Dear Rene, > On Wed, Aug 22, 2012 at 04:18:07PM +0700, Martin Hosken wrote: > > The next version of the graphite engine (1.2.0) will have some new API functions added and some deprecated. As a result we need to increase the interface number and we can also increase the age (since we aren't changing or deleting any functions). > > Forgive me, but what ends up as/in the SONAME as of those? > > > Thus we are going from 2.0.0 to 3.0.1 (this is separate from the release numbering scheme). > > Ah, so this will be -3.0.1 as SONAME then. Bad. > > > I.e. we will be binary backwardly compatible with the existing API. > > Then you don't need to change it :) OK. Here's where I share my confusion (hence raising the issue). My understanding (which is probably wrong) is that if you add functions to your API and then an application uses those functions (which we want to encourage and deprecate some other ones for future removal), then how can that application be sure that it has the right version of library that has the new functions? I was assuming you had to bump the interface number in that case. Or is it sufficient to bump the bug fix number and we could go to 2.1.0? It would be much easier to stay at 2.0.0 if we can. So I am all in favour of finding an interpretation of the rules that lets us not change things. Your expertise and experience here would be valued, Rene. > If you ever *remove* the now-deprecated functions that's an other matter > as you then become binary-incompatible, yes, but now... Yes. This will have to happen one day. But for the longer we can delay that, the better. Thanks, Yours, Martin |
From: Sharon C. <sha...@si...> - 2012-08-22 22:03:48
|
[Sorry for cross-posting--this is really a development question, but I need input from people who know about the Graphite fonts in existence.] There has been an "infelicity" in the Graphite1 (SilGraphite) engine, which has suddenly become a bug, and I need some input on how to fix it. In normal cases, when you attach one glyph to another, Graphite will add guard space, that is, adjust the position and advance width of the base glyph to account for the attached glyphs and their advance widths. The exception is: if the advance width of the attached glyph (eg, diacritic or combining mark) is exactly 0, then this will not be done. The "infelicity" was that the special test for advance-width = 0 was only being applied to the advance of the base (ie, how the right side of the glyph looks), not for the position of the left side of the base. I recently realized this is wrong, but I have been hesitant to change it because I didn't want to break existing fonts. Now I realize that the "infelicity" is actually a bug for RTL fonts. In RTL fonts, the left side of the glyph actually is positioned using the advance width. So taking into account attached glyphs creates guard space in the advance width when it is not wanted. Guard space is bad in cursive scripts--you almost never want it. I could fix the bug "correctly", which could possibly have the effect of breaking existing fonts. Those that would be affected would be those with combining marks that overhang on the left-hand side and have been counting on the guard space that is created. Or I could fix the bug specifically for the RTL case, so it at least won't affect LTR fonts. |
From: Rene E. <re...@de...> - 2012-08-22 10:26:35
|
On Wed, Aug 22, 2012 at 04:18:07PM +0700, Martin Hosken wrote: > The next version of the graphite engine (1.2.0) will have some new API functions added and some deprecated. As a result we need to increase the interface number and we can also increase the age (since we aren't changing or deleting any functions). Forgive me, but what ends up as/in the SONAME as of those? > Thus we are going from 2.0.0 to 3.0.1 (this is separate from the release numbering scheme). Ah, so this will be -3.0.1 as SONAME then. Bad. > I.e. we will be binary backwardly compatible with the existing API. Then you don't need to change it :) > Is there anything we should be doing to reduce the impact on packagers and application integrators as we do this? Feel free to pull the code and take a look (hg clone http://hg.palaso.org/graphitedev). You don't need to change the SONAME if you only *add* new functipon and do not *remove* (or change signatures). That would help much. For only new functions we can just make anything using it depend onm >= whetevr version, if the SONAME was bumped we needed a rebuild of everything depending on it... If you ever *remove* the now-deprecated functions that's an other matter as you then become binary-incompatible, yes, but now... Regards, Rene |
From: Martin H. <mar...@si...> - 2012-08-22 09:18:22
|
Dear All, The next version of the graphite engine (1.2.0) will have some new API functions added and some deprecated. As a result we need to increase the interface number and we can also increase the age (since we aren't changing or deleting any functions). Thus we are going from 2.0.0 to 3.0.1 (this is separate from the release numbering scheme). I.e. we will be binary backwardly compatible with the existing API. Is there anything we should be doing to reduce the impact on packagers and application integrators as we do this? Feel free to pull the code and take a look (hg clone http://hg.palaso.org/graphitedev). As you can see we are working to keep API changes to a minimum and to minimise the impact of those changes. So we hope we don't have to do this very often. Yours, Martin |
From: Christoph H. <c_h...@ar...> - 2012-08-14 05:56:02
|
Hello, sorry for the incomplete mail. I was going to change the language for spell checking and ended up pressing the send button. From my point of view, I would say simpler is better in this situation. I can't really imagine a situation where saving 25K would really be necessary. Just removing any rarely used switches seems more helpful. Easier documentation/support, fewer sources of errors or bugs... And if someone thinks he needs a smaller library, he/she can always use the size optimization provided by the compiler. Best regards, Christoph On 14.08.2012 06:26, Martin Hosken wrote: > Dear All, > > We have a few -D type switches for disabling the compilation of code. Of course we could support any number of these and give all kinds of refinements (don't compile justification support, etc.). The question I have for everyone is: how much size saving justifies the addition of a switch. For example, the current sizes of a release build are: > > Include everything: 145K > -DNTRACING saves 10K > -DNFILEFACE saves 5K > -DNSEGCACHE saves 10K > > are we getting to the point of diminishing returns? > > Yours, > Martin > > ------------------------------------------------------------------------------ > 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: Christoph H. <c_h...@ar...> - 2012-08-14 05:46:31
|
Hello, from my point of view, I would say simpler is better in this situation. On 14.08.2012 06:26, Martin Hosken wrote: > Dear All, > > We have a few -D type switches for disabling the compilation of code. Of course we could support any number of these and give all kinds of refinements (don't compile justification support, etc.). The question I have for everyone is: how much size saving justifies the addition of a switch. For example, the current sizes of a release build are: > > Include everything: 145K > -DNTRACING saves 10K > -DNFILEFACE saves 5K > -DNSEGCACHE saves 10K > > are we getting to the point of diminishing returns? > > Yours, > Martin > > ------------------------------------------------------------------------------ > 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: Martin H. <mar...@si...> - 2012-08-14 04:26:47
|
Dear All, We have a few -D type switches for disabling the compilation of code. Of course we could support any number of these and give all kinds of refinements (don't compile justification support, etc.). The question I have for everyone is: how much size saving justifies the addition of a switch. For example, the current sizes of a release build are: Include everything: 145K -DNTRACING saves 10K -DNFILEFACE saves 5K -DNSEGCACHE saves 10K are we getting to the point of diminishing returns? Yours, Martin |
From: Sharon C. <sha...@si...> - 2012-07-27 15:41:06
|
Done--but it might take a while before the change shows up! On 7/26/2012 10:48 PM, Shriramana Sharma wrote: > grcompiler-4.2/compiler/GrcErrorList.cpp > > You might like to insert: > > strmOut << ".\n" ; > > before the WriteErrorsToStream function's closing brace on line 290. > Otherwise no newline is added at the end of gdlerr.txt. > > > > ------------------------------------------------------------------------------ > 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: Shriramana S. <sa...@gm...> - 2012-07-27 12:40:38
|
https://bugs.freedesktop.org/show_bug.cgi?id=52575 https://bugs.freedesktop.org/show_bug.cgi?id=52577 https://bugs.freedesktop.org/show_bug.cgi?id=52582 -- Shriramana Sharma |
From: Shriramana S. <sa...@gm...> - 2012-07-27 03:49:13
|
grcompiler-4.2/compiler/GrcErrorList.cpp You might like to insert: strmOut << ".\n" ; before the WriteErrorsToStream function's closing brace on line 290. Otherwise no newline is added at the end of gdlerr.txt. -- Shriramana Sharma |
From: Shriramana S. <sa...@gm...> - 2012-07-24 08:39:39
|
On Tue, Jul 24, 2012 at 1:39 PM, Martin Hosken <mar...@si...> wrote: > Unfortunately the original developer died. Sorry to hear that. My point was not about being able to switch off and on Graphite. I thought this extension was also supposed to provide a GUI to select features. That is the functionality I'm looking for. -- Shriramana Sharma |
From: Martin H. <mar...@si...> - 2012-07-24 08:10:03
|
Dear Shriramana, > > https://github.com/thanlwinsoft/groooext/ > > > > This seems somewhat unmaintained and for OOo. It would be very useful > > though to increase usability of Graphite fonts in applications? Could > > this possibly be integrated into LibO (or at least provided as an > > extension) without too much effort? The primary aim of this extension was to allow people to turn off graphite because it was being too slow. Now graphite isn't so the need is alleviated. If you want to take over the maintanence, feel free. Unfortunately the original developer died. Yours, Martin |
From: Shriramana S. <sa...@gm...> - 2012-07-24 06:32:54
|
Hi just a ping on this thread. Martin, Sharon, Bob, anyone? On Sat, Jun 30, 2012 at 10:42 AM, Shriramana Sharma <sa...@gm...> wrote: > https://github.com/thanlwinsoft/groooext/ > > This seems somewhat unmaintained and for OOo. It would be very useful > though to increase usability of Graphite fonts in applications? Could > this possibly be integrated into LibO (or at least provided as an > extension) without too much effort? > > -- > Shriramana Sharma -- Shriramana Sharma |
From: Martin H. <mar...@si...> - 2012-07-13 02:26:46
|
Dear All, This is a heads up on a couple of changes we are intending to make to the gr2 API. While they extend the existing API they also inherently cause some existing functions to be deprecated. The exact details will emerge as we implement and test. 1. gr_make_face The aim here is to add another parameter which is a gr_free_table_fn that gets called with the appFaceHandle and the pointer returned from gr_get_table_fn once the engine is finished with a table. This means an application no longer has to manage a list of tables and then free them when destroying the face, it can just malloc the table, return that to the engine, and then free the malloced block when called by the gr_free_table_fn callback. Of course this parameter may be NULL to retain current implementation models. Since the existing function is used in most integration contexts, we will try hard not to kill the existing API for now, in order to give people plenty of time to update their code. How long do people want the existing API to hang around? 2. graphite_start_logging_to Due to problems on Windows where the engine may be linked to a different version of mscrt than the application to which it links, we have decided that instead of passing a data structure (which may change structure across versions of mscrt!) we will pass a filename and have the engine open and close the file. While we are at it, to make the engine work better in multithreaded contexts, the logging state will be associated with a face. So you will need to pass a face when starting and stopping logging. Due to the internal complexities of implementing logging, we will not be able to retain the old API. Depending on how people respond, we will either keep the old API for a little while, and make it do nothing, or just delete it. Given that we are messing with the API. Are there other things you would like to see changed? And no we won't tidy up the slight infelicities in naming that I'm sure are in there. Yours, Martin |