"Graphite is a project under development within SIL’s Non-Roman Script Initiative and Language Software Development groups to provide rendering capabilities for complex non-Roman writing systems." (Submitting these two together since pangographite depends on silgraphite, and silgraphite isn't very useful as far as I know without pangographite. Also, dirtyepic asked me to assign this to the fonts team, but I only have permission to cc :-( )
Created attachment 143264 [details] silgraphite-2.3.ebuild The main graphite library. Since upstream doesn't release source tarballs as far as I can see, the ebuild downloads the tarball from mirror://gentoo/, which should be made from svn://scripts.sil.org/graphite/graphite/tags/graphite-2.3/engine
Created attachment 143265 [details, diff] silgraphite-r827-debug-CFLAGS.patch Prevents the configure script from doing naughty things to CFLAGS.
Created attachment 143266 [details] pangographite-0.9.2_pre20080208.ebuild Since there's been no tag of pangographite for a while, I took a snapshot of the trunk: svn://scripts.sil.org/graphite/graphite/trunk/wrappers/pangographite (which I think is probably the same code as svn://scripts.sil.org/graphite/graphite/tags/graphite-2.3/wrappers/pangographite... the directory structure is slightly odd.)
Created attachment 143268 [details, diff] pangographite-r724-debug-CFLAGS.patch
Created attachment 143269 [details, diff] pangographite-r724-check-ftface.patch Fixes an assertion error which I've only been able to trigger (not that I've tried terribly hard) with gnome-inform7, which not in the tree yet - I /think/ it happens when an application tries to use the font at size 0, and causes the standard pango modules to print nasty warning messages, so it's probably a bug in the app, but in any case this prevents it from crashing.
Created attachment 143271 [details, diff] pangographite-r724-fix-locking.patch Fixes an assertion error from pangocairo when browsing with SeaMonkey (most likely any Gecko browser) to http://en.wikipedia.org/wiki/Burmese_script with ttf-sil-padauk installed and increasing and decreasing the font size a few times. This is slightly voodoo, in that I'm not quite sure why it works or whether it's correct....
(In reply to comment #3) > Created an attachment (id=143266) [edit] > pangographite-0.9.2_pre20080208.ebuild The PANGO_RC_FILE stuff in here is rather nasty, but it's necessary to put the graphite module in its own directory at the end of the load path so it can override the standard modules for graphite fonts. Maybe someone can think of a nicer way....
thanks david. ccing gnome as this is pango-related. i haven't had a look yet but this is something i wouldn't mind having support for in gentoo. i'll work on it when i get some time to do font stuff again.
I'm going to be annoying and change the suggested category for pangographite to x11-plugins, because it'll drive me crazy if I don't. Final decision is up to you guys, of course.
Gaah.. it considers Vietnamese scripts "complex rendering". I think I'm in. As these packages have not been released yet, why not make live ebuilds instead?
(In reply to comment #10) > Gaah.. it considers Vietnamese scripts "complex rendering". I think I'm in. > As these packages have not been released yet, why not make live ebuilds > instead? They are released in the sense of tags in svn, mailing list announcements, Ubuntu packages, etc, just not source tarballs. Live ebuilds would certainly be possible if someone wants them, but I don't think there's a great need.
Created attachment 143636 [details] silgraphite-2.3.ebuild Use tarball from sf.net. Disable all wrappers.
Created attachment 143637 [details] pango-graphite-2.3.ebuild Again use source from silgraphite tarball (any reason not to?) Cleaned up src_install a bit. Added pkg_postrm() Change ebuild name to pango-graphite to match ubuntu name. Note that I did not apply your three patches. I don't know what they are for and how to test them. They also seems not applied upstream yet, did you submit upstream?
Created attachment 143638 [details, diff] pango-graphite-2.3-pango-modules.patch
(In reply to comment #13) > Again use source from silgraphite tarball (any reason not to?) Heh, only that I didn't notice it. I took the "NOTE: this Version 1 source code is OBSOLETE: Version 2 is available at: svn://scripts.sil.org/graphite/graphite/trunk." message at the top of the downloads page a bit too seriously.... > Note that I did not apply your three patches. I don't know what they are for > and how to test them. They also seems not applied upstream yet, did you submit > upstream? Not yet. The CFLAGS one is to bring it more in line with Gentoo standards (ie don't interfere with the user's CFLAGS), so it might not be appropriate, but I'll see about doing the others. (In reply to comment #14) > Created an attachment (id=143638) [edit] > pango-graphite-2.3-pango-modules.patch I'm not sure if this is right... the module gets installed in its own directory so we can force it (by putting it at the end of the load path) to override the standard pango modules whenever the font has a Graphite table. Does that still happen with the patch (ie is the graphite module listed at the end of pango.modules)? And if so, is it reliable, or just a quirk of the filesystem returning files in the order they were created? If it does work though, it'll certainly simplify things....
(In reply to comment #12) > Created an attachment (id=143636) [edit] > silgraphite-2.3.ebuild > > Use tarball from sf.net. Disable all wrappers. You could simplify this a bit by setting S=${WORKDIR}/${P}/engine (much like you do with pango-graphite) then you could drop the pkgconfig dep and the extra configure arguments. Also, SRC_URI is wrong, should be mirror://sourceforge/${PN}/${P}.tar.gz (In reply to comment #13) > Created an attachment (id=143637) [edit] > pango-graphite-2.3.ebuild Again, SRC_URI. Also DESCRIPTION is the same as for silgraphite, a copy-and-paste error? (In reply to comment #15) > I'm not sure if this is right... the module gets installed in its own directory > so we can force it (by putting it at the end of the load path) to override the > standard pango modules whenever the font has a Graphite table. Does that still > happen with the patch (ie is the graphite module listed at the end of > pango.modules)? And if so, is it reliable, or just a quirk of the filesystem > returning files in the order they were created? I checked the pango-querymodules code, and it doesn't have any ordering logic within a single directory other than the order that g_dir_read_name() returns them in. Having said that, I haven't been able to persuade it to return them in the wrong order, but I'm not really comfortable with relying on that.
(In reply to comment #13) > Note that I did not apply your three patches. I don't know what they are for > and how to test them. They also seems not applied upstream yet, did you submit > upstream? I've sent the check-ftface and fix-locking patches to upstream's SourceForge tracker. I didn't do the CFLAGS one because it's not really a bug fix, it just makes the package play better within Gentoo. BTW, I think it would be more appropriate to call the pango-graphite ebuild 0.9.2, rather than 2.3. The latest svn tag and source tarball for pangographite are numbered 0.9.0, but there are debs for 0.9.2 that contain the same code as the silgraphite-2.3 tarball. The ebuild should continue to use the current tarball, since we're making the user download it anyway, so the only change would be to use "MP=silgraphite-2.3" instead of "MP=silgraphite-${PV}".
Created attachment 143818 [details] silgraphite-2.3.ebuild Fixed SRC_URI, S, src_compile()
Created attachment 143820 [details] pango-graphite-2.3.ebuild Fixed SRC_URI, DESCRIPTION. Reapplied your patches. Put PANGO_RC_FILE back.
BTW, patches may need a bit of modification due to ${S} changes in both ebuilds. (In reply to comment #16) > I checked the pango-querymodules code, and it doesn't have any ordering logic > within a single directory other than the order that g_dir_read_name() returns > them in. Having said that, I haven't been able to persuade it to return them > in the wrong order, but I'm not really comfortable with relying on that. > Yeah. Really hate to pollute env.d but there seems no way else. While at it, why wouldn't you put graphite path before standard path? I think you would want pango-graphite to have higher precendence than standard modules. (In reply to comment #17) > BTW, I think it would be more appropriate to call the pango-graphite ebuild > 0.9.2, rather than 2.3. The latest svn tag and source tarball for > pangographite are numbered 0.9.0, but there are debs for 0.9.2 that contain the > same code as the silgraphite-2.3 tarball. The ebuild should continue to use > the current tarball, since we're making the user download it anyway, so the > only change would be to use "MP=silgraphite-2.3" instead of > "MP=silgraphite-${PV}". > Too late I attached new ebuilds already j/k. Will make it 0.9.2
(In reply to comment #20) > BTW, patches may need a bit of modification due to ${S} changes in both > ebuilds. Seems to work for me, epatch is fairly forgiving about that sort of thing. > (In reply to comment #16) > > I checked the pango-querymodules code, and it doesn't have any ordering logic > > within a single directory other than the order that g_dir_read_name() returns > > them in. Having said that, I haven't been able to persuade it to return them > > in the wrong order, but I'm not really comfortable with relying on that. > > > > Yeah. Really hate to pollute env.d but there seems no way else. I'm hoping one of the gnome people (already CCed) will have a better idea.... > While at it, why wouldn't you put graphite path before standard path? I think you > would want pango-graphite to have higher precendence than standard modules. You'd think so, but pango apparently takes the last module that matches, not the first.
Created attachment 144031 [details] pango.eselect I thought about this a bit more, and wrote an eselect module and eclass for ebuilds that install pango modules. I'm attaching them here, and if people like it (especially gnome people, since they're the ones that'll be maintaining it...) I'll post them to -dev for review.
Created attachment 144033 [details] pango-module.eclass
Created attachment 144035 [details, diff] pango-1.18.4.ebuild.patch Patch against pango-1.18.4.ebuild, to demonstrate the usage of the eclass.
Created attachment 144037 [details, diff] emul-linux-x86-gtklibs-20071214.ebuild.patch Patch against emul-linux-x86-gtklibs-20071214.ebuild to demonstrate usage of the eclass. The src_install is rather ugly, but hopefully it won't be necessary once the package is built using a pango version that uses the eclass, as then the necessary env.d file will be included in the tarball.
Created attachment 144038 [details, diff] pango-graphite-2.3.ebuild.patch Patch against the above pango-graphite-2.3.ebuild, to demonstrate usage of the eclass.
Created attachment 144043 [details] pango-module.eclass Updated eclass: reorder the functions so the most important ones appear at the top of the man page, and use a slightly less hackish way to avoid adding extra deps to emul-linux-x86-gtklibs.
Created attachment 144045 [details, diff] emul-linux-x86-gtklibs-20071214.ebuild.patch Updated emul- patch.
It's probably best to make a separate bug for pango eselect module and make this bug depend on that.
(In reply to comment #29) > It's probably best to make a separate bug for pango eselect module and make > this bug depend on that. > OK, filed bug 210884 for that.
Created attachment 144365 [details, diff] pangographite-r724-check-is-fc-font.patch Additional patch (submitted upstream) to avoid breaking anything using PangoX (only one I know is pango-view --backend=x).
silgraphite and pango-graphite compile and work fine on my stable x86 system.
silgraphite's in the tree. can this be closed?
Assuming so.
