Issue 93645 - Add a Graphite module to support Graphite Smart Fonts
Summary: Add a Graphite module to support Graphite Smart Fonts
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 3.0
Hardware: All All
: P3 Trivial with 6 votes (vote)
Target Milestone: OOo 3.2
Assignee: devel
QA Contact: issues@gsl
Depends on:
Blocks: 69129
  Show dependency tree
Reported: 2008-09-09 06:10 UTC by devel
Modified: 2010-01-04 12:20 UTC (History)
6 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
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: Contact: kstribley
URL for Product Information:
URL for License:
Type of Encryption: none
Binary or Source Code: Source code from
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 )

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

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

Keith Stribley
Comment 1 Martin Hollmichel 2008-09-22 07:25:16 UTC
start review
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 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
Having read, 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 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
Comment 8 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 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 2008-12-11 15:57:57 UTC
With feature freeze for OOo31 being today ( 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])

is that really intended to stay so?
Comment 13 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 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 thing is
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.


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
+	fi

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 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 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
Close issue.