|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Add a Graphite module to support Graphite Smart Fonts | ||
|---|---|---|---|
| Product: | gsl | Reporter: | devel |
| Component: | code | Assignee: | devel |
| Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> |
| Severity: | Trivial | ||
| Priority: | P3 | CC: | fonts-bugs, hans-joachim.lankenau, hdu, ich, issues, rene |
| Version: | OOo 3.0 | ||
| Target Milestone: | OOo 3.2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
| Issue Depends on: | |||
| Issue Blocks: | 69129 | ||
|
Description
devel
2008-09-09 06:10:20 UTC
start review @hdu: can you please give further guidance for getting the cws done, please. . 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. @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. @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. Thanks for your tips. The graphite module is now in the graphite01 CWS at http://svn.services.openoffice.org/ooo/cws/graphite01/graphite/ @kstribely: thanks! Is everything ready, i.e. is everything commited that needs to be commited? 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. @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. 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 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?
> 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?
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. 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 :-) mmh, actually I am wrong, the tarball is in svn. So the configure.in thing is obsolete. @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 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. 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 The graphite module is present and working in the graphite01 CWS. Fixed in graphite01 CWS Great job, thanks! I hope to get around to testing this when OOo3.1.1 and CWS otf01 are done. Verified that the module is in the CWS graphite01. Close issue. |