silgraphite-devel — SILGraphite development

Re: [Silgraphite-devel] [Silgraphite-fonts] Tamil Brahmi font using Graphite

[Shriramana S. <sa...@gm...>]

On Fri, Jun 22, 2012 at 10:21 PM, Bobby de Vos <bob...@si...> wrote:
> I would say that would be a good thing. If I have the time, I was hoping
> to convert some non-unicode indic fonts my organization has to Unicode,
> using Graphite and OpenType. So if Graphite was added to Lohit fonts,
> that would give even more choices when selecting a font.

Not sure I follow your logic. Granted, adding Gr to Lohit family would
enable selection of features but how does your conversion of
non-Unicode to Unicode relate to this? Is it your hope (a not
unjustified one) that with OFL-ed GDL programs available for Indic
more people can create Indic fonts with only the glyphs available (by
just compiling against the GDL)?

-- 
Shriramana Sharma

Re: [Silgraphite-devel] Andika font missing from your Ubuntu repo

[Neil M. <nei...@si...>]

On 2012-06-21 3:30 PM Neil Mayhew wrote:
> I'll fix this in the next couple of days.

I just migrated a bunch of architecture-independent packages from
oneiric to precise, including fonts:

bibledit-gtk-data 4.2.67-2+natty1
fontforge-doc 0.0.20090915-1lucid1
fonts-sil-annapurnasil 1.001-web-1ubuntu3
fonts-sil-charissil 4.110-web-1ubuntu8
fonts-sil-doulossil 4.110-web-1ubuntu8
fonts-sil-gentium-basic 1.1-developer-1ubuntu4
fonts-sil-gentium-plus 1.508-developer-1ubuntu8
fonts-sil-gentiumbasic 1.1-developer-1ubuntu4
fonts-sil-gentiumplus 1.508-developer-1ubuntu8
fonts-sil-gentiumpluscompact 1.508-1ubuntu4
libencode-registry-perl 0.13-1intrepid1.1
libencode-utr22-perl 0.17
libfont-ttf-perl 0.47-1ubuntu1-lucid1
libfont-ttf-scripts-perl 0.16.1.1+1
libtext-pdf-perl 0.30-1-lucid1
sil-archive-keyring 2008.10.27sil1+lucid1
ttf-sil-charis 4.110-web-1ubuntu8
ttf-sil-doulos 4.110-web-1ubuntu8
ttf-sil-padauk 2.80
wsi-autotools 0.1.5-0ubuntu1+lucid1

Let me know if you have any more problems.

--Neil

Re: [Silgraphite-devel] Fwd: Firefox 13 and LO 3.7 problem with rendering Brahmi using Graphite

[Shriramana S. <sa...@gm...>]

Anyone looked into or try to reproduce this bug?

Sent from my Android phone
On Jun 21, 2012 11:36 PM, "Shriramana Sharma" <sa...@gm...> wrote:

> Just this evening I posted to the silgraphite-fonts list about our
> Adinatha Tamil Brahmi font available from
> http://www.virtualvinodh.com/download/Adinatha-Tamil-Brahmi.zip.
> Before releasing I tested the Gr programming in it with LO 3.5 and all
> was fine.
>
> However I've now discovered that there is some problem in rendering in
> LO 3.7 (testing version
>
> http://dev-builds.libreoffice.org/daily/Win-x86@6-fast/master/current/master~2012-06-14_22.09.53_LibO-Dev_3.7.0alpha0_Win_x86_install_en-US.msi
> downloaded a few days back) and in Fx 13.
>
> I've made a ZIP of the glyphs-only TTF which served as a ref for the
> GDL, the GDL file, the compiled TTF with Gr tables, sample HTML for
> Fx, Fx rendering as PDF, ODT for LO, LO 3.5 rendering and LO 3.7
> rendering as PDFs.
>
> I'll keep it at
>
> https://sites.google.com/site/jamadagni/files/brahmi-graphite-testing-20120621.zip
> till it can be tested.
>
> As noted, the LO 3.5 rendering is the control version with all being
> as it should be.
>
> The problem with LO 3.7 is that with LLA and LLA only, the vowel signs
> are attached to the consonant but are duplicated and once more
> displayed in their nominal form.
>
> Fx 3.7 also does this for LLA, but it also has the problem that for
> all consonants, the short vowels E/O, which are indicated in Tamil
> Brahmi by the long vowels E/O with a dot (called pulli in Tamil) as a
> vowel-shortener, are not rendered properly, because the pulli (dot)
> component is duplicated (as all VS-s are duplicated for LLA). [Also
> note how the two problems cross-over for short vowels E/O with LLA!]
>
> I think my GDL program is not faulty as LO 3.5 produces the
> appropriate output and it is only on LO 3.7 and Fx 13 that I have a
> problem. I don't use WorldPad much as I find it somewhat awkward to
> use all that "New Writing System" stuff and esp since it doesn't work
> on Linux. [I haven't tried it via Wine.] So right now I can test/use
> Graphite only on LO and Fx [which is good though] -- I haven't gotted
> around to learning XeTeX usage.
>
> Can the matter please be looked into? Thanks!
>
> --
> Shriramana Sharma
>

Re: [Silgraphite-devel] [Silgraphite-fonts] Tamil Brahmi font using Graphite

[Bobby de V. <bob...@si...>]

On 12-06-21 08:39 PM, Shriramana Sharma wrote:
> Besides, I am not really sure what is the point of the same font
> having both tables? I mean if Graphite were to offer some serious
> improvement in rendering, but the OT rendering is acceptable as a
> fallback, then one would include both OT and Gr, and apps which don't
> support Gr would fall back to OT. But in this case of Lohit fonts
> being recast to use Gr, whatever precision improvement would result
> from using Gr should ideally be implemented in OT in the future (if
> RedHat doesn't want to switch totally to Gr which is unlikely). 

I could see an advantage of Graphite in the font being support for
features. Then you could select variant characters, all from a single
font. OpenType supports this as well, but if I recall correctly, some
applications like LibreOffice support Graphite features, but not
OpenType features.

> Basically the only purpose of writing a Gr version of the Lohit fonts
> would be to showcase a complete set of Indic fonts (for the major
> Indic scripts) using Graphite. Do you feel that be a Good Thing (TM)? 

I would say that would be a good thing. If I have the time, I was hoping
to convert some non-unicode indic fonts my organization has to Unicode,
using Graphite and OpenType. So if Graphite was added to Lohit fonts,
that would give even more choices when selecting a font.

Cheers,
Bobby

-- 
Bobby de Vos
/bob...@si.../

Re: [Silgraphite-devel] [Silgraphite-fonts] Tamil Brahmi font using Graphite

[Shriramana S. <sa...@gm...>]

Going back onlist.

On Fri, Jun 22, 2012 at 1:43 AM, Sharon Correll <sha...@si...> wrote:
> On Thu, Jun 21, 2012 at 11:47 PM, Shriramana Sharma <sa...@gm...> wrote:
> > On Thu, Jun 21, 2012 at 10:53 PM, Shriramana Sharma <sa...@gm...> wrote:
> >> Can you please take the publicly released Lohit Tamil TTF, strip it of
> >> all OT tables and send it to me?
> >
> > Hmm now I've used my favourite font editor (from High Logic) to remove
> > the GDEF, GPOS and GSUB tables. I suppose that should be enough?
> >
> > And would you say that modifying the Lohit fonts this way would
> > necessitate changing its name as the name "Lohit" would be reserved?
> > Maybe we can even have a series of "Krishna" Indic fonts which are the
> > same as Lohit with OT stripped out and Gr added (in due course of
> > time). [Lohit = Red, for "Red Hat". Krishna = Black, for "Graphite"!
> > :-)]
> >
> > Using Gr would seriously help optimizing these fonts. For example
> > https://bugzilla.redhat.com/show_bug.cgi?id=825115 (which I reported)
> > would be easily fixed using Graphite.
>
> It's not clear to me why you'd need to remove the OT tables at all. I don't
> think the OFL would require that, and certainly there is no technological
> problem with supporting both OT and Graphite in a single font.

Of course I understand that. I did note that our Brahmi font had both
Gr and OT tables didn't I. My point about removing OT tables was to
make sure that whatever rendering is happening is solely due to Gr and
not the app falling back to OT while I'm testing. (Or is that fear
unnecessary?)

Besides, I am not really sure what is the point of the same font
having both tables? I mean if Graphite were to offer some serious
improvement in rendering, but the OT rendering is acceptable as a
fallback, then one would include both OT and Gr, and apps which don't
support Gr would fall back to OT. But in this case of Lohit fonts
being recast to use Gr, whatever precision improvement would result
from using Gr should ideally be implemented in OT in the future (if
RedHat doesn't want to switch totally to Gr which is unlikely).

> You probably do need to change the name of the font, though, unless you
> could get permission to call it something like "Lohit Graphite".

Basically the only purpose of writing a Gr version of the Lohit fonts
would be to showcase a complete set of Indic fonts (for the major
Indic scripts) using Graphite. Do you feel that be a Good Thing (TM)?

-- 
Shriramana Sharma

Re: [Silgraphite-devel] Andika font missing from your Ubuntu repo

[Neil M. <nei...@si...>]

On 2012-06-21 9:00 AM Shriramana Sharma wrote:
> the Padauk font is not actually available from said location.
> http://packages.sil.org/ubuntu/dists/precise/main/binary-all/fonts/
> has only Andika. Why is this?

Sorry, this didn't get migrated from oneiric when precise came out. I'll
fix this in the next couple of days.

Re: [Silgraphite-devel] Fwd: Firefox 13 and LO 3.7 problem with rendering Brahmi using Graphite

[Sharon C. <sha...@si...>]

On 6/21/2012 1:06 PM, Shriramana Sharma wrote:
> I don't use WorldPad much as I find it somewhat awkward to
> use all that "New Writing System" stuff and esp since it doesn't work
> on Linux.

By the way, you don't really *have* to use the Writing System 
mechanism on WorldPad just for simple tests. Graphite should still 
work fine just with any default language assigned, as long as the 
right font is selected.

But the Linux thing, yes, sigh. There was work done on a WorldPad for 
Linux, but it never got completed. :-(

[Silgraphite-devel] Fwd: Firefox 13 and LO 3.7 problem with rendering Brahmi using Graphite

[Shriramana S. <sa...@gm...>]

Just this evening I posted to the silgraphite-fonts list about our
Adinatha Tamil Brahmi font available from
http://www.virtualvinodh.com/download/Adinatha-Tamil-Brahmi.zip.
Before releasing I tested the Gr programming in it with LO 3.5 and all
was fine.

However I've now discovered that there is some problem in rendering in
LO 3.7 (testing version
http://dev-builds.libreoffice.org/daily/Win-x86@6-fast/master/current/master~2012-06-14_22.09.53_LibO-Dev_3.7.0alpha0_Win_x86_install_en-US.msi
downloaded a few days back) and in Fx 13.

I've made a ZIP of the glyphs-only TTF which served as a ref for the
GDL, the GDL file, the compiled TTF with Gr tables, sample HTML for
Fx, Fx rendering as PDF, ODT for LO, LO 3.5 rendering and LO 3.7
rendering as PDFs.

I'll keep it at
https://sites.google.com/site/jamadagni/files/brahmi-graphite-testing-20120621.zip
till it can be tested.

As noted, the LO 3.5 rendering is the control version with all being
as it should be.

The problem with LO 3.7 is that with LLA and LLA only, the vowel signs
are attached to the consonant but are duplicated and once more
displayed in their nominal form.

Fx 3.7 also does this for LLA, but it also has the problem that for
all consonants, the short vowels E/O, which are indicated in Tamil
Brahmi by the long vowels E/O with a dot (called pulli in Tamil) as a
vowel-shortener, are not rendered properly, because the pulli (dot)
component is duplicated (as all VS-s are duplicated for LLA). [Also
note how the two problems cross-over for short vowels E/O with LLA!]

I think my GDL program is not faulty as LO 3.5 produces the
appropriate output and it is only on LO 3.7 and Fx 13 that I have a
problem. I don't use WorldPad much as I find it somewhat awkward to
use all that "New Writing System" stuff and esp since it doesn't work
on Linux. [I haven't tried it via Wine.] So right now I can test/use
Graphite only on LO and Fx [which is good though] -- I haven't gotted
around to learning XeTeX usage.

Can the matter please be looked into? Thanks!

--
Shriramana Sharma

[Silgraphite-devel] Andika font missing from your Ubuntu repo

[Shriramana S. <sa...@gm...>]

I'm not sure this is the right forum for this but if it is not please forgive:

>From http://scripts.sil.org/Padauk:

<quote>
The Debian package is available for Ubuntu by adding the line:
deb  http://packages.sil.org/ubuntu distro main
to the list of repositories.
</quote>

but the Padauk font is not actually available from said location.
http://packages.sil.org/ubuntu/dists/precise/main/binary-all/fonts/
has only Andika. Why is this?

Thank you.

-- 
Shriramana Sharma

Re: [Silgraphite-devel] Adding feature aliases to gr

[Shriramana S. <sa...@gm...>]

On Fri, Jun 8, 2012 at 9:56 PM, Martin Hosken <mar...@si...> wrote:
> XeTeX could well be the slowest of all.

IIUC XeTeX has not been ported to gr2 at all! Or has that status changed now?

-- 
Shriramana Sharma

Re: [Silgraphite-devel] Adding feature aliases to gr

[Martin H. <mar...@si...>]

On Fri, 08 Jun 2012 10:18:22 -0500
Bob Hallissy <Bob...@si...> wrote:

> On 2012-06-08  at 9:29  Sharon Correll wrote:
> > On 6/6/2012 9:07 PM, Martin Hosken wrote:
> >> >  But please remember that OpenOffice (as opposed to LibreOffice) may well be the last application that will support feature aliases.
> > I have no idea what you're saying here. Are you just saying that there
> > might not be any later versions of OOo that support Graphite? Because
> > it sounds like you're saying that LibreOffice will never support
> > feature aliases, and that doesn't make sense.
> 
> We also struggled to interpret this -- finally figured out he meant:  LO 
> is unlikely to ever support feature aliases. (As in, everyone else will 
> support aliases long before LO does).

No, I intended nearly the opposite. What I was trying to say is that if you formed a line in order of which applications will get feature aliases first, OpenOffice could well be near the far end (slowest to receive) of the list. Anything running gr2 would get it pretty soon (well 4 months max wait). XeTeX could well be the slowest of all.

Yours,
Martin

Re: [Silgraphite-devel] Adding feature aliases to gr

[Shriramana S. <sa...@gm...>]

But the application needs to provide an interface for them no?

Anyway why won't LO support them? M

Sent from my Android phone
On Jun 8, 2012 8:56 PM, "Sharon Correll" <sha...@si...> wrote:

> On 6/8/2012 10:18 AM, Bob Hallissy wrote:
> > On 2012-06-08  at 9:29  Sharon Correll wrote:
> >> On 6/6/2012 9:07 PM, Martin Hosken wrote:
> >>>>   But please remember that OpenOffice (as opposed to LibreOffice) may
> well be the last application that will support feature aliases.
> >> I have no idea what you're saying here. Are you just saying that there
> >> might not be any later versions of OOo that support Graphite? Because
> >> it sounds like you're saying that LibreOffice will never support
> >> feature aliases, and that doesn't make sense.
> > We also struggled to interpret this -- finally figured out he meant:  LO
> > is unlikely to ever support feature aliases. (As in, everyone else will
> > support aliases long before LO does).
>
> But I'm still confused. It is not the application that needs to
> support the aliases, it is the Graphite engine.
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [Silgraphite-devel] Adding feature aliases to gr

[Sharon C. <sha...@si...>]

On 6/8/2012 10:18 AM, Bob Hallissy wrote:
> On 2012-06-08  at 9:29  Sharon Correll wrote:
>> On 6/6/2012 9:07 PM, Martin Hosken wrote:
>>>>   But please remember that OpenOffice (as opposed to LibreOffice) may well be the last application that will support feature aliases.
>> I have no idea what you're saying here. Are you just saying that there
>> might not be any later versions of OOo that support Graphite? Because
>> it sounds like you're saying that LibreOffice will never support
>> feature aliases, and that doesn't make sense.
> We also struggled to interpret this -- finally figured out he meant:  LO
> is unlikely to ever support feature aliases. (As in, everyone else will
> support aliases long before LO does).

But I'm still confused. It is not the application that needs to 
support the aliases, it is the Graphite engine.

Re: [Silgraphite-devel] Adding feature aliases to gr

[Bob H. <Bob...@si...>]

On 2012-06-08  at 9:29  Sharon Correll wrote:
> On 6/6/2012 9:07 PM, Martin Hosken wrote:
>> >  But please remember that OpenOffice (as opposed to LibreOffice) may well be the last application that will support feature aliases.
> I have no idea what you're saying here. Are you just saying that there
> might not be any later versions of OOo that support Graphite? Because
> it sounds like you're saying that LibreOffice will never support
> feature aliases, and that doesn't make sense.

We also struggled to interpret this -- finally figured out he meant:  LO 
is unlikely to ever support feature aliases. (As in, everyone else will 
support aliases long before LO does).

B

Re: [Silgraphite-devel] Adding feature aliases to gr

[Sharon C. <sha...@si...>]

On 6/6/2012 9:07 PM, Martin Hosken wrote:
> But please remember that OpenOffice (as opposed to LibreOffice) may well be the last application that will support feature aliases.

I have no idea what you're saying here. Are you just saying that there 
might not be any later versions of OOo that support Graphite? Because 
it sounds like you're saying that LibreOffice will never support 
feature aliases, and that doesn't make sense.

Re: [Silgraphite-devel] Adding feature aliases to gr

[Sharon C. <sha...@si...>]

On 6/6/2012 3:37 AM, Martin Hosken wrote:
> One way to achieve this would be to use a v2 Feat table. An alias entry in that table (say "cv05" is to be an alias of "lita") would look like this:
>
> id = "cv05"
> numSettings = 0
> reserved = index of "lita" featuredefn in the list of features + 1 (thus the first index is 1)
> offset = 0
> flags = 0x8000 (because the old engine wants that)
> label = 0

On the other hand, one of the problems with this approach is that for 
fonts with a large number of features, we will still be running into 
the limit of 64 features per font. Now this is a "limitation of the 
engine implementation", not the font tables themselves, so supposedly 
the engine could be modified, and it might not apply to Graphite2 
anyway. But it would still break old engines, or rather, new fonts 
with aliases would just not work at all (they would revert to 
built-in/dumb behavior).

Ideally there would be a way to do this that would not be affected by 
the limit. But to do that we'd probably need a separate table that old 
engines wouldn't choke on.

Re: [Silgraphite-devel] Adding feature aliases to gr

[Martin H. <mar...@si...>]

Dear Alan,

> >> then presumably we could equally do:
> >>
> >>     id = (1024, "lita", "cv05")
> >>
> >> is that right?
> >
> > Sure, I would think so.
> I think this is an important feature for the team developing our Roman 
> fonts. Some of us really don't want old docs (which use numeric feature 
> ids (1024)) to break when a font (which supports the new tag-like ids 
> (lita)) is updated. I hope to discuss this at our meeting tomorrow.

But please remember that OpenOffice (as opposed to LibreOffice) may well be the last application that will support feature aliases. I don't know what's happening within OpenOffice with respect to Graphite integration. OpenOffice requires all source code contributions to be Apache Licensed, and silgraphite isn't so licensed, and graphite2 never will be (it will always be a copy left license, although saying the word "always" is risky).

One way is to make the 1024 the dominant feature, then you won't break old documents, but neither will users of older applications be able to use the new feature ids. That may be sufficient. That's your call. It depends if you want to kill off the old numbers or have to keep them in the documentation for the foreseeable future and explain all that to users.

GB,
Martin

Re: [Silgraphite-devel] Adding feature aliases to gr

[Alan W. <ala...@si...>]

> Sharon Correll wrote:
>
> On 6/6/2012 1:57 PM, Bob Hallissy wrote:
>> Assuming we can do something like:
>>
>>     id = ("lita", "cv05")
>>
>> then presumably we could equally do:
>>
>>     id = (1024, "lita", "cv05")
>>
>> is that right?
>
> Sure, I would think so.
I think this is an important feature for the team developing our Roman 
fonts. Some of us really don't want old docs (which use numeric feature 
ids (1024)) to break when a font (which supports the new tag-like ids 
(lita)) is updated. I hope to discuss this at our meeting tomorrow.

Alan Ward

Re: [Silgraphite-devel] Adding feature aliases to gr

[Sharon C. <sha...@si...>]

On 6/6/2012 1:57 PM, Bob Hallissy wrote:
> Assuming we can do something like:
>
>     id = ("lita", "cv05")
>
> then presumably we could equally do:
>
>     id = (1024, "lita", "cv05")
>
> is that right?

Sure, I would think so.

Re: [Silgraphite-devel] Adding feature aliases to gr

[Bob H. <Bob...@si...>]

On 2012-06-06  at 3:37  Martin Hosken wrote:
> What do folks feel. Is this a feature worth implementing?

We had an impromptu discussion about this problem earlier today. The 
REAL bite is not the "cv05" vs "lita" problem, but rather the pending 
backwards incompatibility (unless some kind of alias mechanism is worked 
out) of updated fonts (that use alphanumeric IDs) and /existing 
documents/ (that use numeric IDs).

Assuming we can do something like:

    id = ("lita", "cv05")

then presumably we could equally do:

    id = (1024, "lita", "cv05")

is that right?

> In the old engine (unpatched) this would have the effect of adding a feature with no settings into the feature list.
Shame about that, however.

Bob

[Silgraphite-devel] Adding feature aliases to gr

[Martin H. <mar...@si...>]

Dear Sharon,

In discussions with Tim about adding feature aliases to graphite, I think we can retrofit these in a way that won't cripple the old engine. Basically here's the approach.

The aim is to allow more than one id to reference the same feature. So, for example, if someone wanted to both use sensible feature ids and also parallel opentype features, they may want to have both the feature id "cv05" and "lita" reference the same feature and so be used interchangeably.

One way to achieve this would be to use a v2 Feat table. An alias entry in that table (say "cv05" is to be an alias of "lita") would look like this:

id = "cv05"
numSettings = 0
reserved = index of "lita" featuredefn in the list of features + 1 (thus the first index is 1)
offset = 0
flags = 0x8000 (because the old engine wants that)
label = 0

In the old engine (unpatched) this would have the effect of adding a feature with no settings into the feature list. To this end, aliases should be added to the end of the list of features. A patched engine and the new engine would spot the signature (0 offset, reserved > 0) and make a true alias. This is actually pretty simple to do in memory, so that's nice.

The compiler would have to be aware of aliases and it's up to you how you would add them to the syntax. Perhaps we allow id = ("lita", "cv05") and have an array there, or whatever is easiest for you. Notice that only the first in the list will actually work in the old engine, so you'll need to make sure that any references to "cv05" in the GDL point to "lita", or else just expect the font to not work at all well in old unpatched engines. This also applies to unpatched gr2 engines, which will not handle the aliases either.

So the cost of supporting aliases is:

Wait for Firefox 16 (or 4 month wait at worse)
OpenOffice needs some help, not sure. Anyone working on the OpenOffice code base these days?
FW will need to upgrade to a patched silgraphite or preferably work on integrating graphite2
LibreOffice will need a code push to new graphite2. So that's a 2-6 month lag.
Summary: you can have aliases but you will have to wait 4 months to get them from the time we implement.

What do folks feel. Is this a feature worth implementing?

GB,
Martin

[Silgraphite-devel] Graphite2 1.1.3 released

[Martin H. <mar...@si...>]

Dear All,

This is to announce the immediately availability of Graphite2 v1.1.3 from:

http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.1.3.tgz/download
http://projects.palaso.org/attachments/download/242/graphite2-1.1.3.tgz

The changes are pretty minor, but there is one I want to point out to packagers, after the list:

    . Default build has GRAPHITE2_COMPARE_RENDERER to OFF to reduce dependencies
    . Builds on Mac with clang
    . Debug output improvements
    . Tidy up perl wrappers
    . Fuzz tester improvements
    . Various bug fixes for bad font handling

The first change in the list is that we have turned off building comparerenderer by default. This makes it easier for people to just download the package and build it without needing many dependencies. Testing still occurs against the regression standards, but we don't do a comparison check between graphite2 and silgraphite as part of the default make test. The advantage is that graphite2 is no longer build dependent on libgraphite any more. If you want to keep the old testing then you'll need to add -DGRAPHITE2_COMPARE_RENDERER=ON to the cmake -G command line.

The additions to debugging mean that we can soon start making the latest developments available in graphite IDEs. Watch this space :)

Yours,
Martin

[Silgraphite-devel] Perl wrapper failing

[Alan W. <ala...@si...>]

I've been trying to use the Perl wrapper for the latest Graphite engine 
under Ubuntu. I got a fresh copy of the latest code from Mercurial and 
built the engine and the wrapper. The wrapper will load (Build test 
passes), but when I run an example script (gr2fonttest.pl), it fails 
with this error:

perl gr2fonttest.pl CharisSIL-R.ttf "hello world"

Can't locate object method "make_font" via package 
"Text::Graphite2::Face" at gr2fonttest.pl line 39.

I've also tried the same things under Windows 7 and get basically the 
same error (with a different line number).

Is there anyone on the list with the expertise to debug the Perl wrapper 
written in XS?

Alan Ward
NRSI

[Silgraphite-devel] gr2 1.1.2 released

[Martin H. <mar...@si...>]

Dear All,

The Graphite 2 engine has been released at v1.1.2. Herewith the relevant bit from the ChangeLog:

    . Support feature ids < 4 chars when space padded for inclusion in FF 14.
    . More fuzztesting and removal of causes of valgrind bad reads and sigabrts
    . Remove contrib/android into its own repo (http://hg.palaso.org/grandroid)
    . Update comparerenderer to latest harfbuzzng api

Go enjoy. Downloads from the usual places:

http://projects.palaso.org/attachments/download/227/graphite2-1.1.2.tgz
http://sourceforge.net/projects/silgraphite/files/graphite2/graphite2-1.1.2.tgz/download

GB,
Martin

Re: [Silgraphite-devel] building on Windows

[Christoph H. <c_h...@ar...>]

Hello Martin,

now it works, the project and solution files have been generated, thank you for your fast reply.

The second line "cmake . --build --config Release" didn't seem to work (The source directory ...\Release does not exist).
However I suspect it only invokes msbuild on the solution file, is that correct? So it doesn't make much difference if I enter it in the command line manually or actually open the solution and press build.

Best regards,
Christoph

On 10.04.2012 05:53, Martin Hosken wrote:
> Dear Christoph,
>
>> I'm trying to build graphite2-1.1.1 on Windows 7 using Visual Studio 2010.
>> And while I managed to build other projects using CMake I seem to be unable to create the project files for graphite2.
>>
>> I'm using CMake 2.8.7 (more exactly the GUI that is included with CMake).
>> And when I try to build the project files I receive the following error:
>> CMake Error at CMakeLists.txt:8 (set_property):
>>     set_property could not find CACHE variable CMAKE_BUILD_TYPE.  Perhaps it
>>     has not yet been created.
>
> Try doing it from the command line rather than relying on the GUI (You did press configure before generate didn't you? ;)).
>
> cd build
> cmake .. -DGRAPHITE2_COMPARE_RENDERER:BOOL=OFF
>
> we use the -D because comparerenderer has some stiff dependencies, which are possible, but a pain unless you really want to run it. I say that just to offset your next question :) If that doesn't work then you can use -DCMAKE_BUILD_TYPE=Release. Our buildbot does the following, but it's suboptimal:
>
> cd build
> cmake -wno-dev -DCMAKE_BUILD_TYPE=Release -DGRAPHITE2_COMPARE_RENDERER:BOOL=OFF ..
> cmake . --build --config Release
>
>> Now I have multiple questions, some are related to the build process some are not:
>> 1. Has anyone build and used it on Windows before? Is there any additional build documentation available?
>
> Yes we build it automatically from source on Windows whenever we check in new code and we get it to generate VS project files.
>
>> 2. Is Graphite 2 stable? Or is the use of Graphite 1 preferred?
>
> Yes it's stable and the preferred engine for use.
>
> Yours,
> Martin
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Silgraphite-devel mailing list
> Sil...@li...
> https://lists.sourceforge.net/lists/listinfo/silgraphite-devel
>