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: Rene E. <re...@de...> - 2016-01-23 18:41:09
|
Hi, On Sat, Jan 23, 2016 at 11:08:37AM -0600, Martin Hosken wrote: > > Please. > > Ideally including which versions are affected (in my case I'd need to patch > > 1.1.3 and 1.2.4) and which patches fix it... > > There are no patches against 1.2.4 or 1.1.3. As Neil already said, we don't do that[1]. Whether it has a compatible interface or not is not relevant. > Both of these should be upgraded to 1.3.5 which has a compatible interface with all previous versions. If it doesn't then we will work to address that. This is not true. 1.1.3 is libgraphite2.so.2.0.0 1.2.4 and 1.3.5 are libgraphite2.so.3 so at least r-deps need to be rebuilt, too. Which is a no-go[2]. You want us to release a graphite2 and a libreoffice and a ... update? > I'm afraid we have not kept track of precisely which patches provide security level bug fixes and there are a lot between 1.1.3 and 1.3.5. In addition, the code has changed a lot between those versions such that identifying which security bugs apply on which version of the code and even whether the bug fix works in that context is a difficult path to take. Instead it's easier just to upgrade the library. > But it's not what makes most sense. > The project's policy is to ensure backward compatibility at the API level, but not at the feature level. We also don't separate security bug fixes from feature bug fixes. Sometimes the category is easy to identify but often it is not. Then you should start to separate them. Upgrading to a full new release is a no-go (and if API/ABI/SONAME changed is impossible mostly) Regards, Rene [1] except in cases where upstreams behave brokenly and didn't publicalize issues or patches themselves in a sensible manner. Like MySQL... This is NOT the rule. [2] It can happen in cases for [1] but it's rare. |
From: Martin H. <mar...@si...> - 2016-01-23 17:08:46
|
Dear Rene, > Please. > Ideally including which versions are affected (in my case I'd need to patch > 1.1.3 and 1.2.4) and which patches fix it... There are no patches against 1.2.4 or 1.1.3. Both of these should be upgraded to 1.3.5 which has a compatible interface with all previous versions. If it doesn't then we will work to address that. I'm afraid we have not kept track of precisely which patches provide security level bug fixes and there are a lot between 1.1.3 and 1.3.5. In addition, the code has changed a lot between those versions such that identifying which security bugs apply on which version of the code and even whether the bug fix works in that context is a difficult path to take. Instead it's easier just to upgrade the library. The project's policy is to ensure backward compatibility at the API level, but not at the feature level. We also don't separate security bug fixes from feature bug fixes. Sometimes the category is easy to identify but often it is not. Yours, Martin |
From: Rene E. <re...@de...> - 2016-01-22 15:51:47
|
Hi, On Fri, Jan 22, 2016 at 08:55:42AM -0600, Martin Hosken wrote: > The bugs will be disclosed in due course from here: http://www.talosintel.com/vulnerability-reports/ as: > > TALOS-CAN-0058: > A suitably crafted font can result in arbitrary code execution. > > TALOS-CAN-0059: > A suitably crafted font can result in a buffer overflow. OK. > I have no idea *when* the TALOS bugs will be made public, but if anyone really wants the details, I am happy to send them the bug reports offline. Please. Ideally including which versions are affected (in my case I'd need to patch 1.1.3 and 1.2.4) and which patches fix it... Regards, Rene |
From: Martin H. <mar...@si...> - 2016-01-22 14:55:54
|
Dear All, > > The Debian security FAQ says: > > > > If you learn about a security problem, either in one of your own > > packages or in someone else's please always contact the security team. > > If the Debian security team confirms the vulnerability and other vendors > > are likely to be vulnerable as well, they usually contact other vendors > > as well. If the vulnerability is not yet public they will try to > > coordinate security advisories with the other vendors, so all major > > distributions are in sync. > > Which is directed to the package maintainers. > > If it's already public they either prepare packages themselves by using above mentioned > patches or I upload them to the security queue myself (which I did for the LibreOffice updates > in the past) > I don't think that upstreams should contact every individual security team. :) > > But right now we are talking in vain here since the entry in the ChangeLog is to completely > unclear. Whether it's a minimal problem, some fuzz problem (which might or might not be > exploitable, git shows fuzz patches some months old...) or something else. > > That should be cleared up by the graphite2 people first. OK. Here goes. The bugs will be disclosed in due course from here: http://www.talosintel.com/vulnerability-reports/ as: TALOS-CAN-0058: A suitably crafted font can result in arbitrary code execution. TALOS-CAN-0059: A suitably crafted font can result in a buffer overflow. Debian bug: On ARM, use of collision avoidance can result in a misaligned memory access violation. I have no idea *when* the TALOS bugs will be made public, but if anyone really wants the details, I am happy to send them the bug reports offline. Firefox has already been informed and is in process. Yours, Martin |
From: Rene E. <re...@de...> - 2016-01-21 16:22:28
|
On Thu, Jan 21, 2016 at 08:40:13AM -0700, Neil Mayhew wrote: > Ideally, these patches would be provided, eg by contacting the Debian > security team, _before_ the upstream commits are made available publicly. It suffices to make the actual fixes available. And they are in git (see below). > The Debian security FAQ says: > > If you learn about a security problem, either in one of your own > packages or in someone else's please always contact the security team. > If the Debian security team confirms the vulnerability and other vendors > are likely to be vulnerable as well, they usually contact other vendors > as well. If the vulnerability is not yet public they will try to > coordinate security advisories with the other vendors, so all major > distributions are in sync. Which is directed to the package maintainers. If it's already public they either prepare packages themselves by using above mentioned patches or I upload them to the security queue myself (which I did for the LibreOffice updates in the past) I don't think that upstreams should contact every individual security team. :) But right now we are talking in vain here since the entry in the ChangeLog is to completely unclear. Whether it's a minimal problem, some fuzz problem (which might or might not be exploitable, git shows fuzz patches some months old...) or something else. That should be cleared up by the graphite2 people first. Regards, Rene |
From: Neil M. <nei...@si...> - 2016-01-21 16:10:16
|
<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 21/01/16 01:11 AM, Rene Engelhard wrote:<br> <blockquote cite="mid:201...@re..." type="cite">... if it is [an exploitable security bug] people _should_ fix past versions and this of course includes the patch one needs to apply and description of the bug (for the security announcement).<br> </blockquote> <br> There's some implicit information here that needs to be made explicit. Both Debian and Ubuntu operate a policy that security vulnerabilities are _not_ fixed by upgrading to a newer upstream version. Instead, a minimal patch is applied that just fixes the vulnerability and nothing else. See <a class="moz-txt-link-rfc2396E" href="https://wiki.ubuntu.com/StableReleaseUpdates"><https://wiki.ubuntu.com/StableReleaseUpdates></a> for a full explanation.<br> <br> Usually this can be done by cherry-picking the upstream commit(s) that fix the bug, but sometimes there are conflicts. It greatly eases the burden on third-party integrators if the upstream developers can provide those patches, since they're in a much better position to see how to resolve conflicts, if any.<br> <br> Ideally, these patches would be provided, eg by contacting the Debian security team, _before_ the upstream commits are made available publicly. The Debian security FAQ says:<br> <br> <blockquote type="cite">If you learn about a security problem, either in one of your own packages or in someone else's please always contact the security team. If the Debian security team confirms the vulnerability and other vendors are likely to be vulnerable as well, they usually contact other vendors as well. If the vulnerability is not yet public they will try to coordinate security advisories with the other vendors, so all major distributions are in sync.</blockquote> <br> </body> </html> |
From: Rene E. <re...@de...> - 2016-01-21 15:27:05
|
Hi, On Thu, Jan 21, 2016 at 08:12:41AM -0600, John Thomson wrote: > Seems to me that if there is a serious, exploitable security problem we That is the question, yes.. > should first inform any colleagues who might want to patch their products > (e.g., FireFox) before the problem is widely known. No, we shouldn't. One could, but it's not a requirement. If firefox has a embedded copy of graphite2, well... It should use system-graphite and then there is no problem if the distro patches graphite2. And the problem is already known. No details, and not widely (just this ML), but known. > After that, I would think a public announcement should try to give some > details of the scope of the problem (i.e., how much damage could be done > by exploiting it?) without giving details that would greatly help hackers. You need to give the exact patch to have stuff patched. And when one releases the patch it gets public whatsoever. At least for patching older versions. One can "sneak" a new graphite 1.3.5 into development, that doesn't help for fixing (if it is affected) graphite2 | 1.1.3-1 | wheezy | source graphite2 | 1.2.4-3 | jessie-kfreebsd | source graphite2 | 1.2.4-3 | jessie | source for example. > In the end, Graphite is open source. Someone only has to look at the repo > to see what changed recently, and probably, the commit label identifies > exactly the change that fixes a security problem and thus points straight > at what was previously vulnerable. Yes, and that already happened. You already see the commits in github and together with this non-verbose changelog entry people might be able to look this up. This is exactly why one should do such stuff directly with info to get people being able to patch it quickly, not trying to shove it under the carpet. As other (even bigger) projects do responsibly. Regards, Rene |
From: John T. <joh...@si...> - 2016-01-21 15:18:07
|
Seems to me that if there is a serious, exploitable security problem we should first inform any colleagues who might want to patch their products (e.g., FireFox) before the problem is widely known. After that, I would think a public announcement should try to give some details of the scope of the problem (i.e., how much damage could be done by exploiting it?) without giving details that would greatly help hackers. In the end, Graphite is open source. Someone only has to look at the repo to see what changed recently, and probably, the commit label identifies exactly the change that fixes a security problem and thus points straight at what was previously vulnerable. JohnT On Thu, Jan 21, 2016 at 2:11 AM, Rene Engelhard <re...@de...> wrote: > On Wed, Jan 20, 2016 at 08:01:39PM -0600, Martin Hosken wrote: > > Dear Rene, > > > > > On Wed, Jan 20, 2016 at 03:01:22PM -0600, Martin Hosken wrote: > > > > 1.3.5 > > > > . Bug fixes > > > > . Security bug fix > > > > > > Hm? What? Details? What versions affected? What is the bug/fix? > > > Will we need to fix past versions? > > > > I don't know the principles here. Is it best to give full disclosure or > just give that it's a security bug fix and therefore people should fix past > versions ideally? > > If it was a "real" exploitable security bug, yes. And IMHO "or" in your > above sentence does not make sense at all - did you mean "and"?; if it is > one > people _should_ fix past versions and this of course includes the patch one > needs to apply and descriprion of the bug (for the security announcement). > > See e.g. http://www.debian.org/security/ > > And now since it's in the changelog/the announcement, everyone knows there > is "something" now anyway... > > Regards, > > Rene > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Silgraphite-devel mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-devel > |
From: Rene E. <re...@de...> - 2016-01-21 08:36:40
|
On Wed, Jan 20, 2016 at 08:01:39PM -0600, Martin Hosken wrote: > Dear Rene, > > > On Wed, Jan 20, 2016 at 03:01:22PM -0600, Martin Hosken wrote: > > > 1.3.5 > > > . Bug fixes > > > . Security bug fix > > > > Hm? What? Details? What versions affected? What is the bug/fix? > > Will we need to fix past versions? > > I don't know the principles here. Is it best to give full disclosure or just give that it's a security bug fix and therefore people should fix past versions ideally? If it was a "real" exploitable security bug, yes. And IMHO "or" in your above sentence does not make sense at all - did you mean "and"?; if it is one people _should_ fix past versions and this of course includes the patch one needs to apply and descriprion of the bug (for the security announcement). See e.g. http://www.debian.org/security/ And now since it's in the changelog/the announcement, everyone knows there is "something" now anyway... Regards, Rene |
From: Martin H. <mar...@si...> - 2016-01-21 02:28:06
|
Dear Rene, > On Wed, Jan 20, 2016 at 03:01:22PM -0600, Martin Hosken wrote: > > 1.3.5 > > . Bug fixes > > . Security bug fix > > Hm? What? Details? What versions affected? What is the bug/fix? > Will we need to fix past versions? I don't know the principles here. Is it best to give full disclosure or just give that it's a security bug fix and therefore people should fix past versions ideally? Yours, Martin |
From: Rene E. <re...@de...> - 2016-01-20 22:34:18
|
Hi, On Wed, Jan 20, 2016 at 03:01:22PM -0600, Martin Hosken wrote: > 1.3.5 > . Bug fixes > . Security bug fix Hm? What? Details? What versions affected? What is the bug/fix? Will we need to fix past versions? That one is not enough info at all and too brief. Regards, Rene |
From: Martin H. <mar...@si...> - 2016-01-20 21:32:58
|
Dear All, Announcing the latest release of the Graphite2 engine. This is just a bug fix release. The files are available from: http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.5.tgz/download http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-minimal-1.3.5.tgz/download https://github.com/silnrsi/graphite/releases/download/1.3.5/graphite2-1.3.5.tgz https://github.com/silnrsi/graphite/releases/download/1.3.5/graphite2-minimal-1.3.5.tgz Those locations also have .sha1sum Notice that the minimal source tree just contains the minimum files needed for building and embedding the graphite library with no tests, etc. The full tree including tests is in the main source tarball. Here is the changelog: 1.3.5 . Bug fixes . Security bug fix . Fix ARM misalignment problem . Track latest cmake Enjoy. GB, Martin |
From: Martin H. <mar...@si...> - 2015-10-22 07:58:45
|
Dear All, The world it is a changing. We have moved! Graphite has joined the great masses and is now hosted on github. The repo may be found at: https://github.com/silnrsi/graphite We are also using the github release mechanisms, so the source tarballs will now come from there. If this is a problem to you, please get in contact and we can work something out, at least for the interim. Announcing release 1.3.4 of the graphite2 engine. This is a bugs only release with only 1 user visible bug being fixed. The complete release source can be downloaded from: https://github.com/silnrsi/graphite/archive/1.3.4.tar.gz https://github.com/silnrsi/graphite/archive/1.3.4.zip In addition, there is a new minimal source tarball for those wishing to embed the graphite engine and not worried about running tests, etc. The tarball is < 200K: https://github.com/silnrsi/graphite/releases/download/1.3.4/graphite2-minimal-1.3.4.tgz This is recommended to most users, unless you are doing full packaging and wanting to run the tests, etc. in which case you will want the full source. As usual, here is the changelog for this release: 1.3.4 . Transition from Mercurial to Git . Bug fixes . Fix Collision Kerning ignoring some diacritics . Handle pass bits 16-31 to speed up fonts with > 16 passes . Various minor fuzz bug fixes . Make Coverity happy . Add GR_FALLTHROUGH macro for clang c++11 Yours, Martin |
From: Martin H. <mar...@si...> - 2015-10-12 07:30:45
|
Dear All, The source repository for the graphite engine has moved to github: https://github.com/silnrsi/graphite Yours, Martin |
From: Martin H. <mar...@si...> - 2015-09-22 06:48:45
|
Dear All, This release is pretty light and is just bug fixes and cleanup. There are a couple of bugs that validate the need for a new release and the timing is to fit with downstream projects. The files are available from the usual places: http://projects.palaso.org/attachments/download/436/graphite2-1.3.3.tgz http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.3.tgz/download The changes are: 1.3.3 . Slight speed up in Collision Avoidance . Remove dead bidi code . Bug fixes . Between pass bidi reorderings and at the end . Decompressor fuzz bugs . Other fuzz bugs Yours, Martin |
From: Martin H. <mar...@si...> - 2015-09-09 08:16:50
|
Dear All, I'm almost scared to release this thing now. But here is the latest attempt. It's been tested against firefox and libreoffice, so that boosts my confidence in it. The source is available from the usual suspects: http://projects.palaso.org/attachments/download/434/graphite2-1.3.2.tgz http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.2.tgz/download The changelog is pretty light, but most of the effort has been in checking that this version really works. . Remove full bidi. All segments are assumed to be single directioned. . Bug fixes: . Decompressor corner cases . Various fuzz bugs The big difference here is that the full bidi has been removed and all segments are assumed to be single directioned. In addition, diacritics now always occur after their bases. But the definition of what is a diacritic, is still up to the font. Go render good strings :) Yours, Martin |
From: Jonathan K. <jfk...@gm...> - 2015-08-31 14:05:25
|
On 31/8/15 14:17, Jonathan Kew wrote: > On 31/8/15 11:59, Martin Hosken wrote: >> Dear All, >> >> Oh blast, there's a bug in the engine and it's pointless running with >> the current release. So there will be a 1.3.2 coming out real soon. >> The 1.3.1 is perfectly good for testing and integration, but will >> fail on some compressed fonts. But since nobody can make compressed >> fonts yet, that's not a problem. >> > > Dear Martin, > > I'm afraid I think there may be another bug in the engine, probably as a > result of the bidi changes...... I tried a test run with 1.3.1 in Gecko, > and hit a crash in graphite2::Segment::reverseSlots(). See > > https://treeherder.mozilla.org/logviewer.html#?job_id=10910728&repo=try > > for more detail. Judging by the crash address (0x8), I assume it's > trying to call the method on a NULL Segment, but I haven't tried to > debug and see exactly where that's coming from. > > (For the testcase that triggers the crash, see > http://mxr.mozilla.org/mozilla-central/source/layout/reftests/text/wordbreak-9.html?force=1.) > ....and in particular, note that this testcase involves shaping segments that contain ONLY an Arabic diacritic. Looking at Segment::reverseSlots(), it appears that if all slots in the segment have bidiClass 16, the |out| pointer never gets set by the loop, so it's still NULL at the end. AFAICS, just wrapping the tail of that method in an |if (out)| condition should fix things: if (out) { out->prev(0); m_last = tlast; m_first = out; } so that a diacritics-only segment is left unchanged; though I haven't thought carefully about whether edge cases such as segments with leading diacritics will actually work properly. JK |
From: Jonathan K. <jfk...@gm...> - 2015-08-31 13:17:11
|
On 31/8/15 11:59, Martin Hosken wrote: > Dear All, > > Oh blast, there's a bug in the engine and it's pointless running with > the current release. So there will be a 1.3.2 coming out real soon. > The 1.3.1 is perfectly good for testing and integration, but will > fail on some compressed fonts. But since nobody can make compressed > fonts yet, that's not a problem. > Dear Martin, I'm afraid I think there may be another bug in the engine, probably as a result of the bidi changes...... I tried a test run with 1.3.1 in Gecko, and hit a crash in graphite2::Segment::reverseSlots(). See https://treeherder.mozilla.org/logviewer.html#?job_id=10910728&repo=try for more detail. Judging by the crash address (0x8), I assume it's trying to call the method on a NULL Segment, but I haven't tried to debug and see exactly where that's coming from. (For the testcase that triggers the crash, see http://mxr.mozilla.org/mozilla-central/source/layout/reftests/text/wordbreak-9.html?force=1.) JK > We'll do some more testing and not rush 1.3.2 out. Probably a week or > so. > > Yours, Martin > >> Announcing the latest graphite engine release. 1.3.1 fixes *lots* >> of bugs in 1.3.0 and 1.2.4. Users of both libraries are recommended >> to upgrade to this release. The source tarballs are available from >> the usual suspects: >> >> http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.1.tgz/download >> >> http://projects.palaso.org/attachments/download/428/graphite2-1.3.1.tgz >> >> There are also sha1sums for those wanting such files: >> >> http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.1.sha1sum/download >> >> http://projects.palaso.org/attachments/download/429/graphite2-1.3.1.sha1sum >> >> And the changelog for this release: >> >> . Deprecation warning: Full bidi support is about to be deprecated. >> Make contact if this impacts you. . Change compression block format >> slightly to conform to LZ4 . Bug fixes: . Handle mono direction >> text with diacritics consistently. Fonts now see the direction they >> expect consistently and bidi now gives expected results. . Fixed >> lots of fuzz bugs . Coverity cleanups . Build now works for clang >> and/or asan and/or afl etc. >> >> The deprecation warning follows on from the previous messages on >> this topic. I know of no applications that pass full paragraphs, >> and therefore the case for keeping the full bidi algorithm is >> suspect. If you have a font that needs special bidi treatment (and >> I suspect there are none of those either) then please contact me. >> TIA. >> >> I'm hoping that we won't be doing another release all that soon. >> But this is software and there are no guarantees. >> >> Yours, Martin > > ------------------------------------------------------------------------------ > > _______________________________________________ > Silgraphite-devel mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-devel > |
From: Martin H. <mar...@si...> - 2015-08-31 10:59:52
|
Dear All, Oh blast, there's a bug in the engine and it's pointless running with the current release. So there will be a 1.3.2 coming out real soon. The 1.3.1 is perfectly good for testing and integration, but will fail on some compressed fonts. But since nobody can make compressed fonts yet, that's not a problem. We'll do some more testing and not rush 1.3.2 out. Probably a week or so. Yours, Martin > Announcing the latest graphite engine release. 1.3.1 fixes *lots* of bugs in 1.3.0 and 1.2.4. Users of both libraries are recommended to upgrade to this release. The source tarballs are available from the usual suspects: > > http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.1.tgz/download > http://projects.palaso.org/attachments/download/428/graphite2-1.3.1.tgz > > There are also sha1sums for those wanting such files: > > http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.1.sha1sum/download > http://projects.palaso.org/attachments/download/429/graphite2-1.3.1.sha1sum > > And the changelog for this release: > > . Deprecation warning: Full bidi support is about to be deprecated. Make contact > if this impacts you. > . Change compression block format slightly to conform to LZ4 > . Bug fixes: > . Handle mono direction text with diacritics consistently. Fonts > now see the direction they expect consistently and bidi now > gives expected results. > . Fixed lots of fuzz bugs > . Coverity cleanups > . Build now works for clang and/or asan and/or afl etc. > > The deprecation warning follows on from the previous messages on this topic. I know of no applications that pass full paragraphs, and therefore the case for keeping the full bidi algorithm is suspect. If you have a font that needs special bidi treatment (and I suspect there are none of those either) then please contact me. TIA. > > I'm hoping that we won't be doing another release all that soon. But this is software and there are no guarantees. > > Yours, > Martin |
From: Martin H. <mar...@si...> - 2015-08-31 03:52:56
|
Dear All, Announcing the latest graphite engine release. 1.3.1 fixes *lots* of bugs in 1.3.0 and 1.2.4. Users of both libraries are recommended to upgrade to this release. The source tarballs are available from the usual suspects: http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.1.tgz/download http://projects.palaso.org/attachments/download/428/graphite2-1.3.1.tgz There are also sha1sums for those wanting such files: http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.3.1.sha1sum/download http://projects.palaso.org/attachments/download/429/graphite2-1.3.1.sha1sum And the changelog for this release: . Deprecation warning: Full bidi support is about to be deprecated. Make contact if this impacts you. . Change compression block format slightly to conform to LZ4 . Bug fixes: . Handle mono direction text with diacritics consistently. Fonts now see the direction they expect consistently and bidi now gives expected results. . Fixed lots of fuzz bugs . Coverity cleanups . Build now works for clang and/or asan and/or afl etc. The deprecation warning follows on from the previous messages on this topic. I know of no applications that pass full paragraphs, and therefore the case for keeping the full bidi algorithm is suspect. If you have a font that needs special bidi treatment (and I suspect there are none of those either) then please contact me. TIA. I'm hoping that we won't be doing another release all that soon. But this is software and there are no guarantees. Yours, Martin |
From: Martin H. <mar...@si...> - 2015-08-29 02:40:59
|
Dear Cambell, > Is the first paragraph supposed to read 'unable to do' No. Graphite can, and actually, after my refactoring, is still able to do paragraph level full bidi processing. But there are limitations: 1. all the characters that occur in the paragraph must be supported by the one font for that paragraph. 2. The whole paragraph has to be passed to graphite because the bidi algorithm needs access to the whole paragraph, you can't pass it part of a paragraph and expect it to work out where it is in the nested depths of embedded isolating ranges of left to right text within right to left within left to right and so on. For this reason, I am considering deprecating the full bidi support in the graphite engine. The upcoming 1.3.1 release will still support full bidi for those that use it. But I know of no use cases where it is used. In all the cases I see, applications do their own bidi analysis at the paragraph level and then break that into runs of equal direction and font and pass those runs as mono direction runs to Graphite. This is the same that happens for things like Harfbuzz. The only two cases where people may cry if we remove bidi are: 1. They are using Graphite to do full bidi at the paragraph level. 2. They have fonts with PUA characters in with non L bidi behaviour, that they want to represent. In the latter case, we may be able to help such people, but there will still be limitations brought on by graphite only having access to a small window of a paragraph. If you are a user of Graphite and fall into either of the above 2 categories, then I would like to hear from you. TIA, Yours, Martin > > C > On 28/08/2015 12:29 pm, "Martin Hosken" <mar...@si...> wrote: > > > Dear All, > > > > We've got bidi wrong and need to fix it. In order to facilitate doing > > things right moving forward I need to know of any applications that are > > using the graphite library that are passing graphite a complete paragraph > > and expecting graphite to do full bidi on that paragraph (which currently > > it is able to do). > > > > Of course I would also love to know of any applications out there that are > > using the graphite library directly. So if you want to confess, now is a > > good time :) > > > > Yours, > > Martin > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Silgraphite-devel mailing list > > Sil...@li... > > https://lists.sourceforge.net/lists/listinfo/silgraphite-devel > > |
From: Cambell <ca...@ar...> - 2015-08-29 00:53:46
|
Hi Is the first paragraph supposed to read 'unable to do' C On 28/08/2015 12:29 pm, "Martin Hosken" <mar...@si...> wrote: > Dear All, > > We've got bidi wrong and need to fix it. In order to facilitate doing > things right moving forward I need to know of any applications that are > using the graphite library that are passing graphite a complete paragraph > and expecting graphite to do full bidi on that paragraph (which currently > it is able to do). > > Of course I would also love to know of any applications out there that are > using the graphite library directly. So if you want to confess, now is a > good time :) > > Yours, > Martin > > > ------------------------------------------------------------------------------ > _______________________________________________ > Silgraphite-devel mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silgraphite-devel > |
From: Martin H. <mar...@si...> - 2015-08-28 05:30:12
|
Dear All, We've got bidi wrong and need to fix it. In order to facilitate doing things right moving forward I need to know of any applications that are using the graphite library that are passing graphite a complete paragraph and expecting graphite to do full bidi on that paragraph (which currently it is able to do). Of course I would also love to know of any applications out there that are using the graphite library directly. So if you want to confess, now is a good time :) Yours, Martin |
From: Martin H. <mar...@si...> - 2015-08-05 04:38:56
|
Dear Shriramana, > I don't seem to find anywhere in the ChangeLog any mention about > supporting cubic outlines, which IIRC was one of the projected future > todo-s – has it already been published and I'm missing the mention? Sorry. That was fixed long ago. The only problem with cubic outlines is that you can't use the bounding box on a glyph since that information is not stored anywhere accessible to Graphite. The engine can run quite happily with no outlines! > Also, you might consider removing the octobox and collision entries > from the ToDo file since they seem to have been done, or am I > mistaken? Will do. Thanks for pointing that out. Yours, Martin |
From: Shriramana S. <sa...@gm...> - 2015-08-05 03:50:52
|
Dear Martin, Thanks for this announcement. I don't seem to find anywhere in the ChangeLog any mention about supporting cubic outlines, which IIRC was one of the projected future todo-s – has it already been published and I'm missing the mention? Also, you might consider removing the octobox and collision entries from the ToDo file since they seem to have been done, or am I mistaken? Thanks again. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा |