Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Add a Graphite module to support Graphite Smart Fonts|
|Status:||CLOSED FIXED||QA Contact:||issues <issues.openoffice.org>|
|Priority:||P3||CC:||fonts-bugs, hans-joachim.lankenau, hdu, ich, issues, rene|
|Target Milestone:||OOo 3.2|
|Issue Type:||ENHANCEMENT||Latest Confirmation on:||---|
|Issue Depends on:|
Description devel 2008-09-09 06:10:20 UTC
Product Name: SIL Graphite Product Version: 2.3 Vendor or Owner Name: SIL International Vendor or Owner Contact: email@example.com OpenOffice.org Contact: kstribley URL for Product Information: http://scripts.sil.org/catgraphite URL for License: http://scripts.sil.org/svn-public/graphite/graphite/trunk/license/ Type of Encryption: none Binary or Source Code: Source code from http://sf.net/projects/silgraphite Purpose: To enable OpenOffice to render Graphite Smart Fonts for complex scripts from around the world. Graphite support is being integrated into OpenOffice in the graphite01 CWS (see i69129 and http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fgraphite01 ) As part of this, we need to link to the Graphite Font Rendering Library. However, SIL are not prepared to jointly assign the copyright of the library itself, only the integration code. The Graphite library is licensed under the CPL 0.5 and LGPL 2.1. This means that the library will need to remain in a separate tar ball or use the version installed on the system (similar to the ICU module). Please can you advise on: a) the procedures to get approval for creating the new module b) the cws/cvs commands to actually create the new module in the graphite01 CWS thanks, Keith Stribley
Comment 1 Martin Hollmichel 2008-09-22 07:25:16 UTC
Comment 2 Martin Hollmichel 2008-09-25 14:39:10 UTC
@hdu: can you please give further guidance for getting the cws done, please.
Comment 3 firstname.lastname@example.org 2008-10-08 13:11:43 UTC
Comment 4 devel 2008-11-04 11:23:32 UTC
Can I go ahead and create the module? Or do I need to wait for another step to happen? Having read http://wiki.services.openoffice.org/wiki/CWS#Create_a_new_module, I assume that I just create a clean directory and then run: cvs co external/libxml2 cd external mkdir graphite cvs add graphite Can I then go ahead and check into it as is on HEAD? The wiki page talks about setting up an alias for it. How do I do that? Do I need to use cwsadd at some point to link it with the graphite01 CWS? Sorry if I'm missing something obvious.
Comment 5 email@example.com 2008-11-18 14:44:05 UTC
@hr: please see Keith's question above, is this the right way? Please guide him through it. @mh: we discussed the graphite integration at OOoCon and all my concerns were addressed. We agreed that once the SCM contains the working integration to review it once more, build the installation sets for QA and get it tested+nominated. The only remaining concern of the impact of the integration on performance is to be tested once the installation sets are ready.
Comment 6 jens-heiner.rechtien 2008-11-18 14:55:31 UTC
@kstribley: The procedure for creating a new module depends on the target for the graphite integration. I assume that it will be the current main development line called DEV300 for OOo-3.1. In this case just create a new top-level directory in Subversion. It would be nice if you mention the new top-level directory in the comment section of the CWS. If, for some reasons, the graphite stuff goes into OO-3.0.x, you'll have to follow the instructions for adding a module to CVS. Any new top-level-directory (module) should follow the typical layout. A <module>/prj directory is mandatory for build.lst and d.lst.
Comment 7 devel 2008-12-03 03:16:03 UTC
Thanks for your tips. The graphite module is now in the graphite01 CWS at http://svn.services.openoffice.org/ooo/cws/graphite01/graphite/
Comment 8 firstname.lastname@example.org 2008-12-03 07:55:07 UTC
@kstribely: thanks! Is everything ready, i.e. is everything commited that needs to be commited?
Comment 9 devel 2008-12-04 03:34:49 UTC
Please could you give me another week. SIL have reported some issues with fallback on Windows, which I would like to test some more. It may need a few more code tweaks.
Comment 10 email@example.com 2008-12-04 09:31:30 UTC
@kstribley: no problem, please take your time so that you feel confident that the CWS will work reliably on all platforms for all use cases. With ChildWorkSpaces like cairocanvastext, kashidafix or maybe even otf01 being already in the queue for OOo31, which all touch related code parts, it may be a wise idea to have graphite01 as an enhancement for a OOo3.2 target.
Comment 11 firstname.lastname@example.org 2008-12-11 15:57:57 UTC
With feature freeze for OOo31 being today (http://wiki.services.openoffice.org/wiki/OOoRelease31) and some other related CWSses in the queue the target 3.1 becomes unrealistic -> updating
Comment 12 rene 2008-12-12 15:42:05 UTC
hdu: at least the tarball is actually *not* in svn and configure does this: if ! test -f ../graphite/download/silgraphite-2.3.tar.gz; then AC_MSG_ERROR([silgraphite tarball not found in graphite/download]) fi is that really intended to stay so?
Comment 13 email@example.com 2008-12-12 16:27:29 UTC
> is that really intended to stay so? I guess not. But I wouldn't consider the CWS complete (from DEV-perspective) until Keith gives his OK. @kstribley: I guess Rene has a point that the tar.gz should be commited @ause: Actually I'm not 100% sure if this is correct? Or should the build process download such files into the download folder of external module's?
Comment 14 rene 2008-12-12 17:13:24 UTC
hdu: right, I was referring to your Dec, 3 comment :-) well, common pratice for (almost) all external modules except the infamous moz is the tarball being in the tree.
Comment 15 rene 2008-12-12 17:18:01 UTC
kstribley: btw, I made SYSTEM_GRAPHITE (which you already check for in graphites makefile.mk) actually checked for and defined and did some more cleanups (-> BUILD_TYPE). Hope you don't mind :-)
Comment 16 rene 2008-12-12 17:46:27 UTC
mmh, actually I am wrong, the tarball is in svn. So the configure.in thing is obsolete.
Comment 17 devel 2008-12-15 11:07:15 UTC
@rene: Thanks for adding the --with-system-graphite option. I've modified the check slightly so that it also checks that the system STL is being used. Otherwise, if you have graphite built with system STL and OOo built with Stlport you will get a crash since graphite uses stl objects in its interface. I also moved the graphite check further down in the sequence order since this seemed to avoid some obscure problems I was getting with --with-system-graphite=no
Comment 18 rene 2008-12-15 11:53:14 UTC
kstribley: you added "-a "$USE_SYSTEM_STL" = "YES";"? I am sorry, but this is broken, this will silently make people use internal mysql when they configured --with-system-mysql. *IF* you add such a check, please make it fail. reverted. Will write a proper check.
Comment 19 rene 2008-12-15 13:17:23 UTC
kstribley: committed + AC_MSG_CHECKING([STL compatibility]) + if test "$WITH_STLPORT" != "no"; then + AC_MSG_ERROR([to use system graphite you need to use --without-stlport]) + else + AC_MSG_RESULT([OK]) + fi instead
Comment 20 devel 2009-06-29 09:32:45 UTC
The graphite module is present and working in the graphite01 CWS.
Comment 21 devel 2009-06-29 09:33:29 UTC
Fixed in graphite01 CWS
Comment 22 firstname.lastname@example.org 2009-06-30 09:21:54 UTC
Great job, thanks! I hope to get around to testing this when OOo3.1.1 and CWS otf01 are done.
Comment 23 email@example.com 2009-07-22 16:16:06 UTC
Verified that the module is in the CWS graphite01.
Comment 24 jens-heiner.rechtien 2010-01-04 12:20:34 UTC