maintenance branch
Hello every one, great thanks to the Fop developpers for their job. I hear here and there about the maintenance branch CVS... is there any chance for a maintenance "release" in the next weeks ? I don't want to disturb anyone with my question. I am just asking because I don't know what is the status of the REC compliance with fop dist. The doc says 0.20.2RC is REC, but... Thanks Cyril - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Redesign vs. maintenance branch
Joerg, I've agreed before with the importance of incremental improvements to the existing base. However, Keiron has been the strongest supporter here of the principle of working from the existing base. His work on the redesign is based, I believe, on his understanding of the existing design, his (and others') efforts to fix the problems over a long period, and his (and others') reluctant conclusion that some new design paradigms were necessary. Do you believe Keiron's understanding to be false? Do you believe that the same result can be achieved by incremental improvements? If so, you may ignore the redesign efforts in good conscience. If your conclusions are not so radical, then it seems to me that, when making major changes to production, you ought to make all reasonable attempts to keep changes in the production branch in sync with the redesign. Your comment about the worrisome things that are still in the redesign underlines this. Evidently, that means more work. But before the redesign goes live, those changes are going to have to be made anyway, and that work will be particularly onerous if it has to happen all at once, rather than piecemeal by the person who writes the changes. Given all of the above, "stealing" code from the unfinished redesign for the maintenance branch, to quote Jeremias, would be essential to make synchronisation in the other direction feasible. Peter P.S. As it happens, I agree that HEAD should represent the production code, and that development should take place on a branch. In this case, though, it would probably just facilitate the isolation of the redesign. J.Pietschmann wrote: > Jeremias Maerki wrote: > >> I'm not so happy about this one. I know I'm also guilty of doing more >> work for the maintenance branch than for the redesign, but "stealing" >> code from the unfinished redesign for the maintenance branch seems to me >> like starting to take its breath away. > > > The problem is that HEAD does not work, and even after > Keiron gets som block and layout out of the door, it will > be far from ready to release. > > One thing which particularly bothers me is that much of > the odd stuff is still in the redesign. Especially it > does not all that much to reduce memory usage, in fact > I have the feeling it will substantially *increase* it. > I wish this Mark Lillywhite character were still around. > > While there are other projects fighting with a HEAD > representing "new idea" stuff and a branch with "tried > technology" for the normal users to check out, IMO it > should be the other way around: have always a working > version in HEAD, make branches to develop new ideas, > and integrate them into HEAD as they mature. -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Redesign vs. maintenance branch
Peter, Joerg, Keiron, Jeremias, others, I don't currently do more than monitor the Fop lists, and if I see a question that pertains to something I wrote, then I'll try to answer it. Since I have not been directly involved with the project for a year, it's not my place to offer opinions on how people should dispose of their time, or how they should direct their energies. Real-life circumstances sidelined me just about the same time we decided to go with a rewrite. I still support that decision for a rewrite. By the time I got back into open-source (and I was away from it for about 6 months), Keiron and Karen were well underway, I no longer had a handle on what they were doing, and in any case too many cooks spoil the broth, so I scratched the itch by striking out with a fork, of sorts. Not really, though - I think the underlying design ideas are very similar - it's just the implementation language that differs. And I've been involved with that for 7 months - anyone who has been following that project knows how much effort has gone into it. I feel it important to point this out - I haven't abandoned Fop by any means, I still keep tabs, it's just that I unavoidably dropped off the cutting edge mainstream, and am now no longer on it. And now I have other commitments. But I have a strong allegiance to Fop, and I'd like to ensure that it stays on track. If I can somehow get back into occasional contributions to the rewrite, I'd like to do that, too. I say "occasional" because that's the reality of it at the moment. I have other things going on right now. I had my day, and now it's time for others, and I see people stepping up to the plate. James Tauber was not indispensable, Fotis Jannidis was not indispensable, I am clearly not indispensable - you get the drift. :-) Peter is involved, Joerg is involved, Jeremias is involved, Bertrand is involved, Christian is a workhorse (:-)), and we have solid developers and contributors - Rhett Aultman, Oleg Tkachenko, Chuck Paussa, etc etc. _And_ we are screwing up because we have _one_ guy - Keiron - doing what is the most important, core work to ensure that Fop stays viable. Karen is busy with real work - period. This happens. So it's Keiron doing the whole thing. And this is obviously not working very well. I've kept tabs on what Joerg has been doing - user support, coding, upcoming plans - and I am very impressed. Problem being, and Peter is right on the money, we've got a lot of effort going into the maintenance branch - high quality effort, mind you - and this strikes me as being inefficient. Joerg, you clearly have a thorough understanding of the spec and the maintenance codebase. What stops you from helping out Keiron? I'm genuinely curious. All we need is one other person. We need to freeze development/feature work on the maintenance branch - that's my humble opinion. At a minimum we need a full and frank exchange of opinions as to what our priorities ought to be. If the committers, OTOH, feel that the maintenance branch can be resuscitated, we need to decide this. I've already seen from what Joerg is doing that this may not be as impossible as I originally thought. But we need to have a pow-wow and make a hard decision. Maybe I am the wrong person to be saying this right now - because I am not currently involved - and maybe I am the right person - because I am not currently involved. In any case, it is said, and I hope we get some good discussion going. Peter, thanks, you started it off. I wouldn't be saying anything at all if I didn't still really care about Fop. Regards, Arved > -Original Message- > From: Peter B. West [mailto:[EMAIL PROTECTED]] > Sent: August 2, 2002 10:18 PM > To: [EMAIL PROTECTED] > Subject: Redesign vs. maintenance branch > > > Joerg, > > I've agreed before with the importance of incremental improvements to > the existing base. However, Keiron has been the strongest supporter > here of the principle of working from the existing base. His work on > the redesign is based, I believe, on his understanding of the existing > design, his (and others') efforts to fix the problems over a long > period, and his (and others') reluctant conclusion that some new design > paradigms were necessary. > > Do you believe Keiron's understanding to be false? Do you believe that > the same result can be achieved by incremental improvements? If so, you > may ignore the redesign efforts in good conscience. If your conclusions > are not so radical, then it seems to me that, when making major changes > to production, you ought to make all reasonable attempts to keep changes > in the production branch in sync with the redesign. Your comment about > the worrisome things that are still in the redesign underlines this. > > Evidently, that mean
Re: Redesign vs. maintenance branch
Peter B. West wrote: > Given all of the above, "stealing" code from the unfinished redesign for > the maintenance branch, to quote Jeremias, would be essential to make > synchronisation in the other direction feasible. > That's exactly what I had in mind. I'm offline now for a week. Good luck! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
basic-link brocken (maintenance branch)
Hi, I just discoverd that basic-link isn't working as expected in the maintenance branch (docs/example/fo/links.fo for example) It seems that mergelinks() is the problem so I'll change the default links.merge to no if there are no objections. (IIRC there has been some discussion about this but a quick search on the mailing list did not find anything) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[maintenance branch] FOP servlet doubled
Hello! FOP sample servlets are now at contrib/servlet directory and look fine, but docs/examples/embedding still contains kind of partial copy - java sources and old buggy fop.war. Lets remove docs/examples/embedding directory altogether or at least this second fop.war? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] more text-decoration (maintenance branch)
Ok,
this should be my last patch for this maintenance release ;-)
It adds inheritance for the text-decoration property from parent inline or
block elements and fixes a bug with non-breaking spaces (but not all)
Christian
Index: docs/examples/fo/textdeko.fo
===
RCS file: /home/cvspublic/xml-fop/docs/examples/fo/textdeko.fo,v
retrieving revision 1.3.4.2
diff -u -r1.3.4.2 textdeko.fo
--- docs/examples/fo/textdeko.fo13 Dec 2001 09:25:21 - 1.3.4.2
+++ docs/examples/fo/textdeko.fo9 Jan 2002 08:47:29 -
@@ -59,7 +59,7 @@
The "text-decoration"-property describes decorations that are added to the text
of an element.
If the property is specified for a block-level element, it should affect all
inline-level descendants
- of the element (does not work yet!).
+ of the element.
If it is specified for (or affects) an inline-level
element, it affects all boxes generated by the element.
@@ -246,12 +246,38 @@
What about underlining of whitespace only ?
-
A whole block should work now.
- And again some more Text to get at least two lines.
+ And again some more text to get at least two lines.
+
+
+
+
+
+
+ Let's see if all inline-areas are affected ...
+
+
+
+
+
+ This is a workaround for
+
+ the combination of
+ different text-decoration values...
+
+
+
+
+
+
+ Enter your name here:
+ _
+
+
+
+
Index: src/org/apache/fop/fo/FObjMixed.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/fo/FObjMixed.java,v
retrieving revision 1.12.2.1
diff -u -r1.12.2.1 FObjMixed.java
--- src/org/apache/fop/fo/FObjMixed.java13 Dec 2001 09:25:21 -
1.12.2.1
+++ src/org/apache/fop/fo/FObjMixed.java9 Jan 2002 08:47:44 -
@@ -36,6 +36,10 @@
super(parent, propertyList);
}
+public TextState getTextState() {
+return ts;
+}
+
protected void addCharacters(char data[], int start, int length) {
// addChild(new FOText(data, start, length, this));
FOText ft = new FOText(data, start, length, this);
Index: src/org/apache/fop/fo/PropertyManager.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/fo/PropertyManager.java,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 PropertyManager.java
--- src/org/apache/fop/fo/PropertyManager.java 13 Dec 2001 09:25:22 - 1.7.2.1
+++ src/org/apache/fop/fo/PropertyManager.java 9 Jan 2002 08:47:46 -
@@ -250,24 +250,50 @@
return props;
}
-public TextState getTextDecoration() throws FOPException {
+public TextState getTextDecoration(FObj parent) throws FOPException {
+
+// TextState from parent Block/Inline
+TextState tsp = null;
+boolean found = false;
+
+do {
+String fname = parent.getName();
+if (fname.equals("fo:flow") || fname.equals("fo:static-content")) {
+found = true;
+} else if (fname.equals("fo:block") || fname.equals("fo:inline")) {
+FObjMixed fom = (FObjMixed) parent;
+tsp = fom.getTextState();
+found = true;
+}
+parent = parent.getParent();
+} while (!found);
+
TextState ts = new TextState();
+if (tsp != null) {
+ts.setUnderlined(tsp.getUnderlined());
+ts.setOverlined(tsp.getOverlined());
+ts.setLineThrough(tsp.getLineThrough());
+}
+
int textDecoration = this.properties.get("text-decoration").getEnum();
-switch (textDecoration) {
-case TextDecoration.UNDERLINE:
+if (textDecoration == TextDecoration.UNDERLINE) {
ts.setUnderlined(true);
-break;
-case TextDecoration.OVERLINE:
+}
+if (textDecoration == TextDecoration.OVERLINE) {
ts.setOverlined(true);
-break;
-case TextDecoration.LINE_THROUGH:
+}
+if (textDecoration == TextDecoration.LINE_THROUGH) {
ts.setLineThrough(true);
-break;
-case TextDecoration.NONE:
+}
+if (textDecoration == TextDecoration.NO_UNDERLINE) {
ts.setUnderlined(false);
+}
+if (textDecoration == TextDecoration.NO_OVERLINE) {
ts.setOverlined(false);
+}
+if (textDecoration == TextDecoration.NO_LINE_THROUGH) {
ts.setLineThrough(false);
}
Index: src/org/apache/fop/fo/flow/Block.java
===
RCS file: /home/cvspublic/xml-fop/
Re: documentation for the maintenance branch
Jeremias Maerki wrote: > We're not really in a hurry, are we? I thought we are... The problem is that DTD and XSL of all documents has to be in sync, a partial commit breaks things :( > If it makes life simpler: +1. The only question arises when we're coming > to the point when we're starting with dev releases of the redesign. > We need different docs for each, right? We should factor out a common set. > I still don't get Jörg's CVS notifications. What can we do to get them > working? I'd really appreciate to know what's going on in CVS. The last checkin showed a "generate commit notification mail" or something, but I didn't get one either. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation for the maintenance branch
Fopdevs, Obviously there is a need for some documention with normal releases. We don't need the design docs in the user releases, but all of the operational material, including the FAQs, is necessary. If we were to do source and compiled releases, the xml-docs could go into the source release, for generation by the user. Vice versa, the generated html (and pdf docs?) need to be included in binary releases (with the proviso above, that the design docs are not needed.) It looks as though reworking is needed in the build.xml to accommodate these distinctions. How does that sound? Peter Christian Geisert wrote: > Hi, > > The documentation is maintained only in the main branch (does > everybody know this?) > > For the RC I just copied the docs from the main branch and > created the archives manually. For the final release I wanted > to have everything in one place (merge docs from trunk into > maintenance branch) but the problem is that stylebook needs > xerces1 which has been replaced with xerces2. > The question is if we should bring xerces1 back or just copy > the docs over (and tag the main branch with fop-0_20_4-doc) > for the release? > > As Keiron already suggested (I had the same thoughts) I think > we should remove xml-docs (and design) from bin distribution. > I'm not sure about removing html-docs from the src distribution. > > Should we remove the docs completly from the maintenance branch? > > PDF generation of the documentation seems to be broken. > > What is the status of the new FAQ? > > Christian > -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation for the maintenance branch
"Peter B. West" <[EMAIL PROTECTED]> wrote: > Obviously there is a need for some documention with normal releases. We > don't need the design docs in the user releases, but all of the > operational material, including the FAQs, is necessary. > > If we were to do source and compiled releases, the xml-docs could go > into the source release, for generation by the user. Vice versa, the > generated html (and pdf docs?) +1 on omitting the design doc completely in bin distributions. Should probably omit skin source and xsl too. I'm not sure about PDF, apparently there are not much requests for this format. What's larger: - PDF - xdocs + *2document.xsl + document2fo + build mechanism for building PDF (includes ant.jar?) - xdocs + full xsl + build mechanism for building PDF This may need some explanation: We have documents using a generic document.dtd and some documents liks FAQs which have to be transformed into document.dtd xdocs before the final skin document2html.xsl can be applied. When using ant for building, this requires either temporary files (current solution) or a custom task for the transformation pipelines (or Cocoon CLI) > need to be included in binary releases > (with the proviso above, that the design docs are not needed.) It looks > as though reworking is needed in the build.xml to accommodate these > distinctions. How does that sound? That's exactly what I'm currently doing, the HTML and the intermediate document-DTD files are produced in the build directory. Unfortunately, as I already noted, it's an all-or-nothing thing unless you are comfortable with broken doc builds for some time. If this is ok, I can commit the first half tomorrow... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation for the maintenance branch
On Thu, 2002-06-27 at 14:39, Joerg Pietschmann wrote: > +1 on omitting the design doc completely in bin distributions. > Should probably omit skin source and xsl too. +1 also. > I'm not sure about PDF, apparently there are not much requests > for this format. > What's larger: > - PDF > - xdocs + *2document.xsl + document2fo + build mechanism for building PDF > (includes ant.jar?) > - xdocs + full xsl + build mechanism for building PDF > This may need some explanation: We have documents using a generic > document.dtd and some documents liks FAQs which have to be > transformed into document.dtd xdocs before the final skin > document2html.xsl can be applied. When using ant for building, > this requires either temporary files (current solution) or a > custom task for the transformation pipelines (or Cocoon CLI) Isn't this the whole idea of forrest. We simply write our docs. Forrest supplies the skin and sitemap and we run the Cocoon using "java" ant task. eg. in forrest they do this: ... args and classpath ... The hardest part is copying all the right files across. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation for the maintenance branch
Joerg, Joerg Pietschmann wrote: > "Peter B. West" <[EMAIL PROTECTED]> wrote: > >>Obviously there is a need for some documention with normal releases. We >>don't need the design docs in the user releases, but all of the >>operational material, including the FAQs, is necessary. >> >>If we were to do source and compiled releases, the xml-docs could go >>into the source release, for generation by the user. Vice versa, the >>generated html (and pdf docs?) > > +1 on omitting the design doc completely in bin distributions. > Should probably omit skin source and xsl too. > I'm not sure about PDF, apparently there are not much requests > for this format. I think html is more generally useful for user support documentation. It would be much, much preferable to keep html and exclude PDF than the reverse. > What's larger: > - PDF > - xdocs + *2document.xsl + document2fo + build mechanism for building PDF > (includes ant.jar?) > - xdocs + full xsl + build mechanism for building PDF > This may need some explanation: We have documents using a generic > document.dtd and some documents liks FAQs which have to be > transformed into document.dtd xdocs before the final skin > document2html.xsl can be applied. When using ant for building, > this requires either temporary files (current solution) or a > custom task for the transformation pipelines (or Cocoon CLI) > Is this xsl part of Forrest, or something you have done? > >>need to be included in binary releases >>(with the proviso above, that the design docs are not needed.) It looks >>as though reworking is needed in the build.xml to accommodate these >>distinctions. How does that sound? > > > That's exactly what I'm currently doing, the HTML and the > intermediate document-DTD files are produced in the build > directory. Unfortunately, as I already noted, it's an > all-or-nothing thing unless you are comfortable with broken > doc builds for some time. > If this is ok, I can commit the first half tomorrow... I think we can live with it. (quietly... a working branch is very handy for this sort of thing...) Peter -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation for the maintenance branch
J.Pietschmann schrieb: [..] > The last checkin showed a "generate commit notification mail" > or something, but I didn't get one either. AFAIK your commit mail needs to be approved once. Best thing would be to ask root. > J.Pietschmann Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation for the maintenance branch
Joerg Pietschmann schrieb: [..] > That's exactly what I'm currently doing, the HTML and the > intermediate document-DTD files are produced in the build > directory. Unfortunately, as I already noted, it's an > all-or-nothing thing unless you are comfortable with broken > doc builds for some time. > If this is ok, I can commit the first half tomorrow... Please wait till after the release. > J.Pietschmann Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation for the maintenance branch
Christian Geisert wrote: > Please wait till after the release. Ok, most issues are solved now, I'll commit it to HEAD this weekend, not that the release is out. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
JDK 1.2 containers in maintenance branch
Hi all, I've replaced most of the JDK 1.0 containers by 1.2 containers in the maintenance branch, ready to commit. The PDF produced from FOP examples compares ok with PDF produced before the conversion. I might have screwed up other renderers, in particular the MIF renderer which required quite a bit more than a simple S&R. I might also have produced additional MT problems, even though I set FOPImageFactory to synchronized. As a side note, I made a script which intercepts GC notifications produced with -verbose:gc and computes total and peak memory. If this can be trusted, using 1.2 containers causes FOP to use 2% less total as well as peak memory. Run time performance is basically the same, apparently Java synchronization doesn't have much effect in a single-threaded environment. If there are no vetoes, I'll commit the change on 2002-08-02, 21:00 CEDST. My plans for the near and not so near future: - vacancy: I'm offline until 2002-08-11 - tracking down the zero width space problem - eleminating the instance data of FONode and as much as possible data of FObj - create the "children" array on demand - resolve doc issues and commit the docs (take deep breath) - implement immutable, reused property bundles and leaner property parsing - integrate image handling and the PDF renderer from head - TR14, spec conformant whitespace handling, linefeed treatment, wrapping and overflow="clip" - rearranging the Area inheritance tree (spaces don't have a height, which is bad), eleminate as much as possible unnecessarily inherited data for inline areas - correct lineheight computation and alignment. Should be enough work... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: basic-link brocken (maintenance branch)
I fixed a bug there, but this obviously brought another. I'll have a look at it. On Wed, 13 Nov 2002 12:17:59 +0100 Christian Geisert wrote: > Hi, > > I just discoverd that basic-link isn't working as expected > in the maintenance branch (docs/example/fo/links.fo for example) > > It seems that mergelinks() is the problem so I'll change > the default links.merge to no if there are no objections. > (IIRC there has been some discussion about this but a quick > search on the mailing list did not find anything) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: basic-link brocken (maintenance branch)
Hi guys, If the problem is that the link rectangles are now merged by default, I am the one that changed it. There was a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9335 and I was doing a bunch of improvements to the positioning of the link rectangles. However, in this case, all I did was change the default merge behavior to yes. Is there something else broken? Regards, Karen Jeremias Maerki wrote: I fixed a bug there, but this obviously brought another. I'll have a look at it. On Wed, 13 Nov 2002 12:17:59 +0100 Christian Geisert wrote: Hi, I just discoverd that basic-link isn't working as expected in the maintenance branch (docs/example/fo/links.fo for example) It seems that mergelinks() is the problem so I'll change the default links.merge to no if there are no objections. (IIRC there has been some discussion about this but a quick search on the mailing list did not find anything) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [maintenance branch] FOP servlet doubled
Yes, dump that directory. That's redundancy. We just have to make sure, that the documentation points the right way, too. On 21.11.2002 20:41:21 Oleg Tkachenko wrote: > FOP sample servlets are now at contrib/servlet directory and look fine, > but docs/examples/embedding still contains kind of partial copy - java > sources and old buggy fop.war. Lets remove docs/examples/embedding > directory altogether or at least this second fop.war? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [maintenance branch] FOP servlet doubled
Jeremias Maerki wrote: Yes, dump that directory. That's redundancy. We just have to make sure, that the documentation points the right way, too. Hmmm, looks like Joerg sees it differently - http://marc.theaimsgroup.com/?l=fop-dev&m=103196215022751&w=2 > Contrib/servlet is not distributed, instead, the Java source > and a war file is in docs/examples/embedding. The war file > in the current distribution has still an old invalid web.xml > in it. So, I'm gonna replace old buggy docs/examples/embedding/fop.war with a new one, generated using /contrib/servlet stuff. What about redundancy - lets wait Joerg is back. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [maintenance branch] FOP servlet doubled
Oleg Tkachenko wrote: Hmmm, looks like Joerg sees it differently - http://marc.theaimsgroup.com/?l=fop-dev&m=103196215022751&w=2 This was a statement of the status quo, which I don't like particularly well. I think the servlet should be moved to src/org/apache/fop/servlet and get a target in the main build.xml file. BTW what about splitting the apps directory into an api and a cli directory, perhaps with new API implementations? In the latter case, the apps directory can be kept for compatibility for a while. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [maintenance branch] FOP servlet doubled
J.Pietschmann wrote: I think the servlet should be moved to src/org/apache/fop/servlet and get a target in the main build.xml file. Wow, not a bad idea. But what about web.xml and servlet.jar, which is required to build it? If it's in main build script we have to be more careful, otherwise it can be one more fop-user-traffic-generator. BTW what about splitting the apps directory into an api and a cli directory, perhaps with new API implementations? In the latter case, the apps directory can be kept for compatibility for a while. I believe it should be done in context of FOP decomposition and avalonization. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [maintenance branch] FOP servlet doubled
Oleg Tkachenko wrote:
Wow, not a bad idea. But what about web.xml and servlet.jar, which is
required to build it? If it's in main build script we have to be more
careful, otherwise it can be one more fop-user-traffic-generator.
web.xml: keep it with the *.java.
servlet.jar: provide a property for the location, defaulting
to lib/servlet.jar. Conditionalize the servlet compilation
on availability of ${servlet.jar}. Users can either copy a
servlet.jar to the lib directory, or use a
-Dservlet.jar=/foo/bar/servlet-2.3.jar
on the command line (or whatever the proper Ant syntax is for
defining properties for the CLI).
BTW what about splitting the apps directory ...
I believe it should be done in context of FOP decomposition and
avalonization.
Me too. I think, however, some "release early" is called for.
The api directory should contain primarily interfaces and some
classes like FOPException which are primarily used by anyone
who wants to use FOP in some Java program. Sort of TrAX for
XSLFO. As long as the classes in apps are kept, not much harm
should be caused by some experiments there.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [maintenance branch] FOP servlet doubled
J.Pietschmann wrote:
web.xml: keep it with the *.java.
servlet.jar: provide a property for the location, defaulting
to lib/servlet.jar. Conditionalize the servlet compilation
on availability of ${servlet.jar}. Users can either copy a
servlet.jar to the lib directory, or use a
-Dservlet.jar=/foo/bar/servlet-2.3.jar
on the command line (or whatever the proper Ant syntax is for
defining properties for the CLI)
Looks ok to me, +1. We should be in time for 0.20.5rc (no CLI of course).
Other opinions?
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [maintenance branch] FOP servlet doubled
J.Pietschmann wrote:
[..]
web.xml: keep it with the *.java.
I would prefer something like src/conf/web.xml
servlet.jar: provide a property for the location, defaulting
to lib/servlet.jar. Conditionalize the servlet compilation
on availability of ${servlet.jar}. Users can either copy a
servlet.jar to the lib directory, or use a
-Dservlet.jar=/foo/bar/servlet-2.3.jar
on the command line (or whatever the proper Ant syntax is for
defining properties for the CLI).
I had planed to remove the old docs/example/embedding and add
the contrib/servlet stuff to the distributen for the release
but if you want to change this I don't mind.
This has at least the advantage of one classpath less to take care of.
Christian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [maintenance branch] FOP servlet doubled
Christian Geisert wrote: I had planed to remove the old docs/example/embedding and add the contrib/servlet stuff to the distributen for the release +1 Sounds as simple while clean enough temporary solution. Lets leave merging contrib/servlet and the main codebase to the trunk? +1 -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] text-decoration for blocks (maintenance branch)
Hi,
this patch adds text-decoration support for blocks. There still some things
I want to do (like inherit text-decoration from a parent inline, problems with
hyphenation and ).
Christian
Index: docs/examples/fo/textdeko.fo
===
RCS file: /home/cvspublic/xml-fop/docs/examples/fo/textdeko.fo,v
retrieving revision 1.3.4.1
diff -u -u -r1.3.4.1 textdeko.fo
--- docs/examples/fo/textdeko.fo2001/12/06 21:28:18 1.3.4.1
+++ docs/examples/fo/textdeko.fo2001/12/11 19:36:36
@@ -77,7 +77,7 @@
line-height="15pt"
space-after.optimum="10pt"
text-align="start">
-This is simple test of the text-decorationunderline.
+This is simple test of the text-decoration 'underline'.
- The following text decorations are defined in the CR:
+ The following text decorations are defined in the REC:
@@ -244,6 +244,12 @@
space-after.optimum="10pt"
text-align="start">
What about underlining of whitespace only ?
+
+
+
+
+ A whole block should work now.
+ And again some more Text to get at least two lines.
Index: src/org/apache/fop/fo/FObjMixed.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/fo/FObjMixed.java,v
retrieving revision 1.12
diff -u -u -r1.12 FObjMixed.java
--- src/org/apache/fop/fo/FObjMixed.java2001/08/01 22:12:52 1.12
+++ src/org/apache/fop/fo/FObjMixed.java2001/12/11 19:36:45
@@ -8,6 +8,7 @@
package org.apache.fop.fo;
import org.apache.fop.layout.Area;
+import org.apache.fop.layout.TextState;
import org.apache.fop.apps.FOPException;
/**
@@ -16,6 +17,9 @@
*/
public class FObjMixed extends FObj {
+// Textdecoration
+protected TextState ts;
+
public static class Maker extends FObj.Maker {
public FObj make(FObj parent,
PropertyList propertyList) throws FOPException {
@@ -33,7 +37,14 @@
}
protected void addCharacters(char data[], int start, int length) {
-addChild(new FOText(data, start, length, this));
+// addChild(new FOText(data, start, length, this));
+FOText ft = new FOText(data, start, length, this);
+ft.setLogger(log);
+ft.setUnderlined(ts.getUnderlined());
+ft.setOverlined(ts.getOverlined());
+ft.setLineThrough(ts.getLineThrough());
+addChild(ft);
+
}
public Status layout(Area area) throws FOPException {
Index: src/org/apache/fop/fo/PropertyManager.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/fo/PropertyManager.java,v
retrieving revision 1.7
diff -u -u -r1.7 PropertyManager.java
--- src/org/apache/fop/fo/PropertyManager.java 2001/08/06 09:12:58 1.7
+++ src/org/apache/fop/fo/PropertyManager.java 2001/12/11 19:36:47
@@ -26,6 +26,8 @@
import java.text.FieldPosition;
import org.apache.fop.layout.Area;
import org.apache.fop.layout.ColumnArea;
+import org.apache.fop.layout.TextState;
+import org.apache.fop.fo.properties.TextDecoration;
public class PropertyManager {
@@ -247,4 +249,29 @@
AbsolutePositionProps props = new AbsolutePositionProps();
return props;
}
+
+public TextState getTextDecoration() throws FOPException {
+TextState ts = new TextState();
+
+int textDecoration = this.properties.get("text-decoration").getEnum();
+
+switch (textDecoration) {
+case TextDecoration.UNDERLINE:
+ts.setUnderlined(true);
+break;
+case TextDecoration.OVERLINE:
+ts.setOverlined(true);
+break;
+case TextDecoration.LINE_THROUGH:
+ts.setLineThrough(true);
+break;
+case TextDecoration.NONE:
+ts.setUnderlined(false);
+ts.setOverlined(false);
+ts.setLineThrough(false);
+}
+
+return ts;
+}
+
}
Index: src/org/apache/fop/fo/flow/Block.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/fo/flow/Block.java,v
retrieving revision 1.41.2.1
diff -u -u -r1.41.2.1 Block.java
--- src/org/apache/fop/fo/flow/Block.java 2001/12/06 21:28:21 1.41.2.1
+++ src/org/apache/fop/fo/flow/Block.java 2001/12/11 19:36:49
@@ -66,10 +66,13 @@
// this may be helpful on other FOs too
boolean anythingLaidOut = false;
-public Block(FObj parent, PropertyList propertyList) {
+public Block(FObj parent, PropertyList propertyList)
+throws FOPException {
+
super(parent, propertyList);
this.name = "fo:block";
this.span = this.properties.get("span").getEnum();
+ts = propMgr.getTextDecoration();
}
public Sta
Re: JDK 1.2 containers in maintenance branch
On 01.08.2002 23:09:32 J.Pietschmann wrote: > Hi all, > I've replaced most of the JDK 1.0 containers by 1.2 containers > in the maintenance branch, ready to commit. The PDF produced > from FOP examples compares ok with PDF produced before the > conversion. I might have screwed up other renderers, in > particular the MIF renderer which required quite a bit more > than a simple S&R. I might also have produced additional > MT problems, even though I set FOPImageFactory to synchronized. > > As a side note, I made a script which intercepts GC notifications > produced with -verbose:gc and computes total and peak memory. > If this can be trusted, using 1.2 containers causes FOP to use > 2% less total as well as peak memory. Run time performance is > basically the same, apparently Java synchronization doesn't > have much effect in a single-threaded environment. > > If there are no vetoes, I'll commit the change on 2002-08-02, > 21:00 CEDST. No veto from me. > My plans for the near and not so near future: > - vacancy: I'm offline until 2002-08-11 > - tracking down the zero width space problem > - eleminating the instance data of FONode and as much >as possible data of FObj > - create the "children" array on demand > - resolve doc issues and commit the docs > (take deep breath) I'm looking forward to this one. > - implement immutable, reused property bundles and leaner >property parsing > - integrate image handling and the PDF renderer from head I'm not so happy about this one. I know I'm also guilty of doing more work for the maintenance branch than for the redesign, but "stealing" code from the unfinished redesign for the maintenance branch seems to me like starting to take its breath away. As Keiron pointed out we have to somehow get the new ball rolling. We have to make the redesign attractive so more people start helping there and so we can finish one day. I intend to help in this direction during my holidays, especially because I won't be able to do so at work at the moment. At work I'm at a point where I can live with the current maintenance branch for a while. But at some point I want to have a new FOP, one that really starts flying. I know the issues you want to handle are important, but I get the impression that the maintenance branch starts to accelerate which is not a good sign. The work would be better invested in the redesign IMO. Flame on... > - TR14, spec conformant whitespace handling, linefeed treatment, >wrapping and overflow="clip" > - rearranging the Area inheritance tree (spaces don't have >a height, which is bad), eleminate as much as possible >unnecessarily inherited data for inline areas > - correct lineheight computation and alignment. > Should be enough work... > > J.Pietschmann Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: JDK 1.2 containers in maintenance branch
Sorry, Joerg. I haven't seen your earlier message where you announced the changes. Should have read the messages in the right order... But my oppinion stands. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: JDK 1.2 containers in maintenance branch
On Fri, 2002-08-02 at 10:10, Jeremias Maerki wrote: > I'm not so happy about this one. I know I'm also guilty of doing more > work for the maintenance branch than for the redesign, but "stealing" > code from the unfinished redesign for the maintenance branch seems to me > like starting to take its breath away. As Keiron pointed out we have to > somehow get the new ball rolling. We have to make the redesign > attractive so more people start helping there and so we can finish one > day. I intend to help in this direction during my holidays, especially > because I won't be able to do so at work at the moment. At work I'm at a > point where I can live with the current maintenance branch for a while. > But at some point I want to have a new FOP, one that really starts > flying. Hopefully I can get some pagination working soon. Unfortunately Karen seems to be busy with other things at the moment. So it may take a bit to sort things out in that area. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: JDK 1.2 containers in maintenance branch
Jeremias Maerki wrote: > I'm not so happy about this one. I know I'm also guilty of doing more > work for the maintenance branch than for the redesign, but "stealing" > code from the unfinished redesign for the maintenance branch seems to me > like starting to take its breath away. The problem is that HEAD does not work, and even after Keiron gets som block and layout out of the door, it will be far from ready to release. One thing which particularly bothers me is that much of the odd stuff is still in the redesign. Especially it does not all that much to reduce memory usage, in fact I have the feeling it will substantially *increase* it. I wish this Mark Lillywhite character were still around. While there are other projects fighting with a HEAD representing "new idea" stuff and a branch with "tried technology" for the normal users to check out, IMO it should be the other way around: have always a working version in HEAD, make branches to develop new ideas, and integrate them into HEAD as they mature. My horizon is to have a 0.20.5rc in two weeks and a release end of august, with a bunch of annoying bugs fixed - lost and reshuffled text (almost done, adding images and fo:characters are still a problem) - space before hyphenated words and related problems (done) - space width calculation (tracked) - text decoration lost (tracked) - links for fo:external-graphics (tracked) - perhaps proper leader resizing for justification (basically move leader generation to LineArea.align()) - solve the page-number-citation right-alignment bug (call Linearea.align() before rendering) - reduced memory usage (in preparation) - perhaps proper linefeed-treatment, white space treatment, overwlow and wrap (prototype almost working) - perhaps enhanced vertical align and baseline-shift - docs and especially the big FAQ, of course. These are problems people post over and over again, and we should keep users somewhat happy by showing soemthing *is* done. See also http://c2.com/cgi/wiki?FixBrokenWindows Note that I'm not trying to add to the mud, actually I'm trying to clean up the maintenance branch bit by bit... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: JDK 1.2 containers in maintenance branch
Joerg, For major changes like this, it would be a good idea to tag the tree before committing. The easiest way, probably, is to get ask someone else with a current version to update and tag before you commit. Peter J.Pietschmann wrote: > Hi all, > I've replaced most of the JDK 1.0 containers by 1.2 containers > in the maintenance branch, ready to commit. The PDF produced > from FOP examples compares ok with PDF produced before the > conversion. I might have screwed up other renderers, in > particular the MIF renderer which required quite a bit more > than a simple S&R. I might also have produced additional > MT problems, even though I set FOPImageFactory to synchronized. > > If there are no vetoes, I'll commit the change on 2002-08-02, > 21:00 CEDST. -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] update FOP (maintenance branch) to REC syntax
Hi, I finally managed to update FOP to REC syntax.. According to the documented changes at: http://www.w3.org/TR/2001/REC-xsl-20011015/sliceF.html#changes http://www.w3.org/TR/2001/PR-xsl-20010828/sliceF.html#changes the biggest thing was the renaming of the "master-name" property to "master-reference" on fo:page-sequence, fo:single-page-master-reference, fo:repeatable-page-master-reference and fo:conditional-page-master-reference. I've also updated all files in docs/examples, run the tests - and it looks good :-) Next I will have a look a the test directory Christian Index: docs/examples/advanced/cid-fonts.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/advanced/cid-fonts.fo,v retrieving revision 1.2 diff -u -u -r1.2 cid-fonts.fo --- docs/examples/advanced/cid-fonts.fo 2001/05/18 09:55:46 1.2 +++ docs/examples/advanced/cid-fonts.fo 2001/12/05 14:11:04 @@ -70,7 +70,7 @@ - + Index: docs/examples/advanced/giro.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/advanced/giro.fo,v retrieving revision 1.1 diff -u -u -r1.1 giro.fo --- docs/examples/advanced/giro.fo 2001/03/04 18:00:38 1.1 +++ docs/examples/advanced/giro.fo 2001/12/05 14:11:18 @@ -10,13 +10,13 @@ - - - + + + - + @@ -1241,4 +1241,4 @@ SVG logo and bar code - \ No newline at end of file + Index: docs/examples/fo/border.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/border.fo,v retrieving revision 1.8 diff -u -u -r1.8 border.fo --- docs/examples/fo/border.fo 2001/10/14 21:03:14 1.8 +++ docs/examples/fo/border.fo 2001/12/05 14:11:20 @@ -13,16 +13,16 @@ - - - + - + Index: docs/examples/fo/bordershorthand.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/bordershorthand.fo,v retrieving revision 1.1 diff -u -u -r1.1 bordershorthand.fo --- docs/examples/fo/bordershorthand.fo 2001/03/04 21:47:40 1.1 +++ docs/examples/fo/bordershorthand.fo 2001/12/05 14:11:21 @@ -48,12 +48,12 @@ - - - + @@ -61,7 +61,7 @@ - + Index: docs/examples/fo/character.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/character.fo,v retrieving revision 1.1 diff -u -u -r1.1 character.fo --- docs/examples/fo/character.fo 2000/12/15 21:44:08 1.1 +++ docs/examples/fo/character.fo 2001/12/05 14:11:21 @@ -39,7 +39,7 @@ the attribute value of master-name refers to the page layout which is to be used to layout the text contained in this page-sequence--> - + - + @@ -61,7 +61,7 @@ - + Index: docs/examples/fo/extensive.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/extensive.fo,v retrieving revision 1.15 diff -u -u -r1.15 extensive.fo --- docs/examples/fo/extensive.fo 2001/06/19 10:47:13 1.15 +++ docs/examples/fo/extensive.fo 2001/12/05 14:11:25 @@ -4,7 +4,7 @@ - + A Block An End Aligned Block Index: docs/examples/fo/fonts.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/fonts.fo,v retrieving revision 1.7 diff -u -u -r1.7 fonts.fo --- docs/examples/fo/fonts.fo 2001/02/13 16:50:54 1.7 +++ docs/examples/fo/fonts.fo 2001/12/05 14:11:26 @@ -18,7 +18,7 @@ - + Index: docs/examples/fo/hyphen.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/hyphen.fo,v retrieving revision 1.4 diff -u -u -r1.4 hyphen.fo --- docs/examples/fo/hyphen.fo 2001/06/07 21:06:13 1.4 +++ docs/examples/fo/hyphen.fo 2001/12/05 14:11:29 @@ -39,7 +39,7 @@ the attribute value of master-name refers to the page layout which is to be used to layout the text contained in this page-sequence--> - + - + - + @@ -71,7 +71,7 @@ - + Index: docs/examples/fo/inhprop.fo ===
[PATCH] update FOP (maintenance branch) to REC syntax
Hi, I finally managed to update FOP to REC syntax.. According to the documented changes at: http://www.w3.org/TR/2001/REC-xsl-20011015/sliceF.html#changes http://www.w3.org/TR/2001/PR-xsl-20010828/sliceF.html#changes the biggest thing was the renaming of the "master-name" property to "master-reference" on fo:page-sequence, fo:single-page-master-reference, fo:repeatable-page-master-reference and fo:conditional-page-master-reference. I've also updated all files in docs/examples, run the tests - and it looks good :-) Next I will have a look a the test directory Christian Index: docs/examples/advanced/cid-fonts.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/advanced/cid-fonts.fo,v retrieving revision 1.2 diff -u -u -r1.2 cid-fonts.fo --- docs/examples/advanced/cid-fonts.fo 2001/05/18 09:55:46 1.2 +++ docs/examples/advanced/cid-fonts.fo 2001/12/05 14:11:04 @@ -70,7 +70,7 @@ - + Index: docs/examples/advanced/giro.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/advanced/giro.fo,v retrieving revision 1.1 diff -u -u -r1.1 giro.fo --- docs/examples/advanced/giro.fo 2001/03/04 18:00:38 1.1 +++ docs/examples/advanced/giro.fo 2001/12/05 14:11:18 @@ -10,13 +10,13 @@ - - - + + + - + @@ -1241,4 +1241,4 @@ SVG logo and bar code - \ No newline at end of file + Index: docs/examples/fo/border.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/border.fo,v retrieving revision 1.8 diff -u -u -r1.8 border.fo --- docs/examples/fo/border.fo 2001/10/14 21:03:14 1.8 +++ docs/examples/fo/border.fo 2001/12/05 14:11:20 @@ -13,16 +13,16 @@ - - - + - + Index: docs/examples/fo/bordershorthand.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/bordershorthand.fo,v retrieving revision 1.1 diff -u -u -r1.1 bordershorthand.fo --- docs/examples/fo/bordershorthand.fo 2001/03/04 21:47:40 1.1 +++ docs/examples/fo/bordershorthand.fo 2001/12/05 14:11:21 @@ -48,12 +48,12 @@ - - - + @@ -61,7 +61,7 @@ - + Index: docs/examples/fo/character.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/character.fo,v retrieving revision 1.1 diff -u -u -r1.1 character.fo --- docs/examples/fo/character.fo 2000/12/15 21:44:08 1.1 +++ docs/examples/fo/character.fo 2001/12/05 14:11:21 @@ -39,7 +39,7 @@ the attribute value of master-name refers to the page layout which is to be used to layout the text contained in this page-sequence--> - + - + @@ -61,7 +61,7 @@ - + Index: docs/examples/fo/extensive.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/extensive.fo,v retrieving revision 1.15 diff -u -u -r1.15 extensive.fo --- docs/examples/fo/extensive.fo 2001/06/19 10:47:13 1.15 +++ docs/examples/fo/extensive.fo 2001/12/05 14:11:25 @@ -4,7 +4,7 @@ - + A Block An End Aligned Block Index: docs/examples/fo/fonts.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/fonts.fo,v retrieving revision 1.7 diff -u -u -r1.7 fonts.fo --- docs/examples/fo/fonts.fo 2001/02/13 16:50:54 1.7 +++ docs/examples/fo/fonts.fo 2001/12/05 14:11:26 @@ -18,7 +18,7 @@ - + Index: docs/examples/fo/hyphen.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/hyphen.fo,v retrieving revision 1.4 diff -u -u -r1.4 hyphen.fo --- docs/examples/fo/hyphen.fo 2001/06/07 21:06:13 1.4 +++ docs/examples/fo/hyphen.fo 2001/12/05 14:11:29 @@ -39,7 +39,7 @@ the attribute value of master-name refers to the page layout which is to be used to layout the text contained in this page-sequence--> - + - + - + @@ -71,7 +71,7 @@ - + Index: docs/examples/fo/inhprop.fo ===
Re: [PATCH] text-decoration for blocks (maintenance branch)
Hi, I have submitted this patch to the branch. On 2001.12.12 19:04 Christian Geisert wrote: > Hi, > > this patch adds text-decoration support for blocks. There still some > things > I want to do (like inherit text-decoration from a parent inline, problems > with > hyphenation and ). > > Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] text-decoration for blocks (maintenance branch)
Christian Geisert wrote: > Hi, > > this patch adds text-decoration support for blocks. There still > some things > I want to do (like inherit text-decoration from a parent inline, > problems with > hyphenation and ). Actually I think fop supports (more or less). Also nonbreaking nbsp and some other space variants (check layout/LineArea) Tore > > Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] text-decoration for blocks (maintenance branch)
Tore Engvig wrote: > > Christian Geisert wrote: > > > Hi, > > > > this patch adds text-decoration support for blocks. There still > > some things > > I want to do (like inherit text-decoration from a parent inline, > > problems with > > hyphenation and ). > > Actually I think fop supports (more or less). Also nonbreaking nbsp > and some other space variants (check layout/LineArea) I meant those problems in context with text-decoration (yes, the text was a bit misleading ;-) like: > Tore Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] fix for looping table bug (maintenance branch)
Hi,
this patch should fix infinite looping on tables if keep_with or row spans are
not fitting on a page. This hack just ignores all keeps for a table after the
first page-break (sounds really simple :-)
It would be better to check if the table starts already on top of the page but
I found no simple way to do this (table-header etc..)
Christian
P.S. I would like to finish the text-decoration patch before the release but
if I don't manage it till tomorrow we should do the release anyway...
diff -ur xml-fop/src/org/apache/fop/fo/flow/RowSpanMgr.java
xml-fop-tab-final/src/org/apache/fop/fo/flow/RowSpanMgr.java
--- xml-fop/src/org/apache/fop/fo/flow/RowSpanMgr.java Mon Jul 30 22:29:23 2001
+++ xml-fop-tab-final/src/org/apache/fop/fo/flow/RowSpanMgr.javaMon Jan 7
+02:36:54 2002
@@ -52,6 +52,8 @@
private SpanInfo spanInfo[];
+private boolean ignoreKeeps = false;
+
public RowSpanMgr(int numCols) {
this.spanInfo = new SpanInfo[numCols];
}
@@ -123,6 +125,24 @@
return spanInfo[colNum - 1].isInLastRow();
} else
return false;
+}
+
+/**
+ * helper method to prevent infinite loops if
+ * keeps or spans are not fitting on a page
+ * @param true if keeps and spans should be ignored
+ */
+public void setIgnoreKeeps(boolean ignoreKeeps) {
+this.ignoreKeeps = ignoreKeeps;
+}
+
+/**
+ * helper method (i.e. hack ;-) to prevent infinite loops if
+ * keeps or spans are not fitting on a page
+ * @return true if keeps or spans should be ignored
+ */
+public boolean ignoreKeeps() {
+return ignoreKeeps;
}
}
diff -ur xml-fop/src/org/apache/fop/fo/flow/TableBody.java
xml-fop-tab-final/src/org/apache/fop/fo/flow/TableBody.java
--- xml-fop/src/org/apache/fop/fo/flow/TableBody.java Mon Aug 6 11:12:59 2001
+++ xml-fop-tab-final/src/org/apache/fop/fo/flow/TableBody.java Mon Jan 7 04:11:51
+2002
@@ -186,8 +186,9 @@
}
return status;
}
-if (keepWith.size()
-> 0) {// && status.getCode() == Status.AREA_FULL_NONE
+if ((keepWith.size() > 0)
+&& (!rowSpanMgr.ignoreKeeps())) {
+// && status.getCode() == Status.AREA_FULL_NONE
// FIXME!!! Handle rows spans!!!
row.removeLayout(areaContainer);
for (Enumeration e = keepWith.elements();
@@ -198,6 +199,10 @@
}
if (i == 0) {
resetMarker();
+
+// Fix for infinite loop bug if keeps are too big for page
+rowSpanMgr.setIgnoreKeeps(true);
+
return new Status(Status.AREA_FULL_NONE);
}
}
@@ -212,6 +217,10 @@
area.increaseHeight(areaContainer.getHeight());
area.setAbsoluteHeight(areaContainer.getAbsoluteHeight());
}
+
+// Fix for infinite loop bug if spanned rows are too big for page
+rowSpanMgr.setIgnoreKeeps(true);
+
return status;
} else if (status.getCode() == Status.KEEP_WITH_NEXT
|| rowSpanMgr.hasUnfinishedSpans()) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] update FOP (maintenance branch) to REC syntax
Christian, Do you think you could put the fixes you sent me, so the inline works across a block ? John XXENDSXX John H. Wyman 5160 Darry Lane Dublin, OH 43016 (614)-889-0698 mailto:[EMAIL PROTECTED] Wyman Genealogy Site <http://www.wyman.org> Francis Wyman Assoc email List http://groups.yahoo.com/group/FrancisWymanAssoc Wyman Family Genealogy Forum <http://genforum.genealogy.com/wyman/> The Wyman Surname Message Board <http://www.familyhistory.com/messages/messages.asp?category=surname&for um=Wyman> -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 05, 2001 10:39 AM To: [EMAIL PROTECTED] Subject: [PATCH] update FOP (maintenance branch) to REC syntax Hi, I finally managed to update FOP to REC syntax.. According to the documented changes at: http://www.w3.org/TR/2001/REC-xsl-20011015/sliceF.html#changes http://www.w3.org/TR/2001/PR-xsl-20010828/sliceF.html#changes the biggest thing was the renaming of the "master-name" property to "master-reference" on fo:page-sequence, fo:single-page-master-reference, fo:repeatable-page-master-reference and fo:conditional-page-master-reference. I've also updated all files in docs/examples, run the tests - and it looks good :-) Next I will have a look a the test directory Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] update FOP (maintenance branch) to REC syntax
"John H. Wyman" wrote: > > Christian, > Do you think you could put the fixes you sent me, so the inline works > across a block ? Yes, I definitely want do it (as time permits..) > John Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] update FOP (maintenance branch) to REC syntax
Thanks! I added the patch to cvs. Tore > Hi, > > I finally managed to update FOP to REC syntax.. > > According to the documented changes at: > > http://www.w3.org/TR/2001/REC-xsl-20011015/sliceF.html#changes > http://www.w3.org/TR/2001/PR-xsl-20010828/sliceF.html#changes > > the biggest thing was the renaming of the "master-name" property to > "master-reference" on fo:page-sequence, fo:single-page-master-reference, > fo:repeatable-page-master-reference and > fo:conditional-page-master-reference. > > I've also updated all files in docs/examples, run the tests - and it looks > good :-) > > Next I will have a look a the test directory > > > Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] update FOP (maintenance branch) to REC syntax
Christian, When is page-position "last" correct implemented ? Claus Christian Geisert cc: Subject: [PATCH] update FOP (maintenance branch) to REC syntax 05-12-2001 16:38 Please respond to fop-dev Hi, I finally managed to update FOP to REC syntax.. According to the documented changes at: http://www.w3.org/TR/2001/REC-xsl-20011015/sliceF.html#changes http://www.w3.org/TR/2001/PR-xsl-20010828/sliceF.html#changes the biggest thing was the renaming of the "master-name" property to "master-reference" on fo:page-sequence, fo:single-page-master-reference, fo:repeatable-page-master-reference and fo:conditional-page-master-reference. I've also updated all files in docs/examples, run the tests - and it looks good :-) Next I will have a look a the test directory Christian Index: docs/examples/advanced/cid-fonts.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/advanced/cid-fonts.fo,v retrieving revision 1.2 diff -u -u -r1.2 cid-fonts.fo --- docs/examples/advanced/cid-fonts.fo 2001/05/18 09:55:46 1.2 +++ docs/examples/advanced/cid-fonts.fo 2001/12/05 14:11:04 @@ -70,7 +70,7 @@ - + Index: docs/examples/advanced/giro.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/advanced/giro.fo,v retrieving revision 1.1 diff -u -u -r1.1 giro.fo --- docs/examples/advanced/giro.fo 2001/03/04 18:00:38 1.1 +++ docs/examples/advanced/giro.fo 2001/12/05 14:11:18 @@ -10,13 +10,13 @@ - - - + + + - + @@ -1241,4 +1241,4 @@ SVG logo and bar code - \ No newline at end of file + Index: docs/examples/fo/border.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/border.fo,v retrieving revision 1.8 diff -u -u -r1.8 border.fo --- docs/examples/fo/border.fo 2001/10/14 21:03:14 1.8 +++ docs/examples/fo/border.fo 2001/12/05 14:11:20 @@ -13,16 +13,16 @@ - - - + - + Index: docs/examples/fo/bordershorthand.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/bordershorthand.fo,v retrieving revision 1.1 diff -u -u -r1.1 bordershorthand.fo --- docs/examples/fo/bordershorthand.fo 2001/03/04 21:47:40 1.1 +++ docs/examples/fo/bordershorthand.fo 2001/12/05 14:11:21 @@ -48,12 +48,12 @@ - - - + @@ -61,7 +61,7 @@ - + Index: docs/examples/fo/character.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/character.fo,v retrieving revision 1.1 diff -u -u -r1.1 character.fo --- docs/examples/fo/character.fo 2000/12/15 21:44:08 1.1 +++ docs/examples/fo/character.fo 2001/12/05 14:11:21 @@ -39,7 +39,7 @@ the attribute value of master-name refers to the page layout which is to be used to layout the text contained in this page-sequence--> - + - + @@ -61,7 +61,7 @@ - + Index: docs/examples/fo/extensive.fo === RCS file: /home/cvspublic/xml-fop/docs/examples/fo/extensive.fo,v retrieving revision 1.15 diff -u -u -r1.15 extensive.fo --- docs/examples/fo/extensive.fo 2001/06/19 10:47:13 1.15 +++ docs/examples/fo/extensive.fo 2001/12/05 14:11:25 @@ -4,7 +4,7 @@ - + A Block An End Aligned
Re: [PATCH] update FOP (maintenance branch) to REC syntax
Claus Nielsen wrote: > > Christian, > > When is page-position "last" correct implemented ? When someone sends a patch ;-) Seriously, I don't know anything about the current status of page-position "last". Maybe Arved can comment on it ? > Claus Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] update test dir to REC syntax (maintenance branch)
Hi, this patch updates the 'test' dir to REC syntax. (just changed master-name to master-reference on page-sequences) I had some problems with strange line endings but I hope it is ok now. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] update test dir to REC syntax (maintenance branch)
Doh, forgot the attachment... this patch updates the 'test' dir to REC syntax. (just changed master-name to master-reference on page-sequences) I had some problems with strange line endings but I hope it is ok now. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] Index: test/errors/foreign.fo === RCS file: /home/cvspublic/xml-fop/test/errors/foreign.fo,v retrieving revision 1.1 diff -u -r1.1 foreign.fo --- test/errors/foreign.fo 2001/10/08 09:55:22 1.1 +++ test/errors/foreign.fo 2001/12/10 00:37:20 @@ -15,7 +15,7 @@ - + Embedding SVG examples Index: test/errors/inavlidxml2.fo === RCS file: /home/cvspublic/xml-fop/test/errors/inavlidxml2.fo,v retrieving revision 1.1 diff -u -r1.1 inavlidxml2.fo --- test/errors/inavlidxml2.fo 2001/10/08 09:55:22 1.1 +++ test/errors/inavlidxml2.fo 2001/12/10 00:37:20 @@ -19,7 +19,7 @@ - + Index: test/errors/unknown.fo === RCS file: /home/cvspublic/xml-fop/test/errors/unknown.fo,v retrieving revision 1.1 diff -u -r1.1 unknown.fo --- test/errors/unknown.fo 2001/10/08 09:55:22 1.1 +++ test/errors/unknown.fo 2001/12/10 00:37:20 @@ -15,7 +15,7 @@ - + Index: test/xml/bugtests/background_color.fo === RCS file: /home/cvspublic/xml-fop/test/xml/bugtests/background_color.fo,v retrieving revision 1.1 diff -u -r1.1 background_color.fo --- test/xml/bugtests/background_color.fo 2001/05/22 13:05:19 1.1 +++ test/xml/bugtests/background_color.fo 2001/12/10 00:37:20 @@ -14,7 +14,7 @@ - + Index: test/xml/bugtests/background_transparent.fo === RCS file: /home/cvspublic/xml-fop/test/xml/bugtests/background_transparent.fo,v retrieving revision 1.1 diff -u -r1.1 background_transparent.fo --- test/xml/bugtests/background_transparent.fo 2001/05/22 13:05:20 1.1 +++ test/xml/bugtests/background_transparent.fo 2001/12/10 00:37:20 @@ -14,7 +14,7 @@ - + This is a simple fo block with transparent background. Index: test/xml/bugtests/block-container.fo === RCS file: /home/cvspublic/xml-fop/test/xml/bugtests/block-container.fo,v retrieving revision 1.1 diff -u -r1.1 block-container.fo --- test/xml/bugtests/block-container.fo2001/05/22 13:05:20 1.1 +++ test/xml/bugtests/block-container.fo2001/12/10 00:37:20 @@ -14,7 +14,7 @@ - + Index: test/xml/bugtests/block.fo === RCS file: /home/cvspublic/xml-fop/test/xml/bugtests/block.fo,v retrieving revision 1.1 diff -u -r1.1 block.fo --- test/xml/bugtests/block.fo 2001/05/22 13:05:20 1.1 +++ test/xml/bugtests/block.fo 2001/12/10 00:37:21 @@ -14,7 +14,7 @@ - + This is a simple fo block. Index: test/xml/bugtests/border.fo === RCS file: /home/cvspublic/xml-fop/test/xml/bugtests/border.fo,v retrieving revision 1.1 diff -u -r1.1 border.fo --- test/xml/bugtests/border.fo 2001/05/22 13:05:20 1.1 +++ test/xml/bugtests/border.fo 2001/12/10 00:37:21 @@ -14,7 +14,7 @@ - + This is a simple fo block. Index: test/xml/bugtests/break-before.fo === RCS file: /home/cvspublic/xml-fop/test/xml/bugtests/break-before.fo,v retrieving revision 1.1 diff -u -r1.1 break-before.fo --- test/xml/bugtests/break-before.fo 2001/05/22 13:05:20 1.1 +++ test/xml/bugtests/break-before.fo 2001/12/10 00:37:21 @@ -14,7 +14,7 @@ - + This is a simple fo block. Index: test/xml/bugtests/charwidth.fo === RCS file: /home/cvspublic/xml-fop/test/xml/bugtests/charwidth.fo,v retrieving revision 1.1 diff -u -r1.1 charwidth.fo --- test/xml/bugtests/charwidth.fo 2001/05/22 13:05:20 1.1 +++ test/xml/bugtests/charwidth.fo 2001/12/10 00:37:22 @@ -5,7 +5,7 @@
Re: [PATCH] fix for looping table bug (maintenance branch)
Hi Christian, Thanks for the patch. It has been applied. On 2002.01.07 18:54 Christian Geisert wrote: > Hi, > > this patch should fix infinite looping on tables if keep_with or row > spans are > not fitting on a page. This hack just ignores all keeps for a table after > the > first page-break (sounds really simple :-) > It would be better to check if the table starts already on top of the > page but > I found no simple way to do this (table-header etc..) > > Christian > > P.S. I would like to finish the text-decoration patch before the release > but > if I don't manage it till tomorrow we should do the release anyway... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] update test dir to REC syntax (maintenance branch)
Christian Geisert wrote: > Doh, forgot the attachment... Ok, it's added to the maintain branch now. Tore > > this patch updates the 'test' dir to REC syntax. > (just changed master-name to master-reference on page-sequences) > > I had some problems with strange line endings but I hope it is ok now. > > Christian > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13919] - Font Refactor, phase 1, maintenance branch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919 Font Refactor, phase 1, maintenance branch --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 08:26 --- Created an attachment (id=3594) tar file containing new Font-related classes -- extract in src/org/apache/fop/fonts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13919] - Font Refactor, phase 1, maintenance branch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919 Font Refactor, phase 1, maintenance branch --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 08:27 --- Created an attachment (id=3595) diffs for maintenance branch to use new font-related classes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13919] New: - Font Refactor, phase 1, maintenance branch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919 Font Refactor, phase 1, maintenance branch Summary: Font Refactor, phase 1, maintenance branch Product: Fop Version: 0.20.4 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The attached tar file contains 3 files, which should be loaded into src/org/apache/fop/fonts -- Font, Typeface, and TypefaceFamily. The attached .txt file contains patches for other files to use these new classes. The substance of this work is to move the layout/FontInfo instances to static information in these new classes. The new classes do not currently have instances of their own, but this should be added in future work. Please note: layout/FontInfo.java should be either removed or deprecated as part of this patch, depending on the project standards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13919] - [Patch] Font Refactor, phase 1, maintenance branch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919 [Patch] Font Refactor, phase 1, maintenance branch [EMAIL PROTECTED] changed: What|Removed |Added Summary|Font Refactor, phase 1, |[Patch] Font Refactor, phase |maintenance branch |1, maintenance branch --- Additional Comments From [EMAIL PROTECTED] 2002-10-24 08:31 --- Changing summary to include keyword [Patch] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13919] - [Patch] Font Refactor, phase 1, maintenance branch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919 [Patch] Font Refactor, phase 1, maintenance branch [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-11-04 15:32 --- As discussed on dev mailing list, we will not do this work in the maintenance branch. This patch will be resubmitted if and when it can be reworked for the trunk. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25997] - [PATCH] Basic OpenType CFF Support for maintenance branch: 3 Patches
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25997>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25997 [PATCH] Basic OpenType CFF Support for maintenance branch: 3 Patches --- Additional Comments From [EMAIL PROTECTED] 2004-01-09 08:38 --- related thread in FOP dev http://marc.theaimsgroup.com/?l=fop-dev&m=107342953607261&w=2
DO NOT REPLY [Bug 25997] New: - [PATCH] Basic OpenType CFF Support for maintenance branch: 3 Patches
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25997>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25997
[PATCH] Basic OpenType CFF Support for maintenance branch: 3 Patches
Summary: [PATCH] Basic OpenType CFF Support for maintenance
branch: 3 Patches
Product: Fop
Version: 0.20.5
Platform: All
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Index: TTFFile.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/fonts/Attic/TTFFile.java,v
retrieving revision 1.6.2.10
diff -w -u -r1.6.2.10 TTFFile.java
--- TTFFile.java20 Sep 2003 21:48:18 - 1.6.2.10
+++ TTFFile.java8 Jan 2004 19:32:42 -
@@ -51,10 +51,14 @@
package org.apache.fop.fonts;
import java.io.IOException;
+
import java.util.ArrayList;
+
import java.util.HashMap;
+
import java.util.Iterator;
+
/**
* Reads a TrueType file or a TrueType Collection.
* The TrueType spec can be found at the Microsoft
@@ -112,6 +116,7 @@
HashMap ansiIndex;
private TTFDirTabEntry currentDirTab;
+private boolean isCFF = false;
/**
* Position inputstream to position indicated
@@ -431,16 +436,22 @@
initAnsiWidths();
readPostscript(in);
readOS2(in);
+if (!isCFF) {
readIndexToLocation(in);
readGlyf(in);
+}
readName(in);
readPCLT(in);
readCMAP(in); // Read cmap table and fill in ansiwidths
createCMaps();// Create cmaps for bfentries
// print_max_min();
+ if (isCFF) {
+ // readGPOS(in); // GPOS is OpenType CFF analog of
TrueType kerning table.
+ } else {
readKerning(in);
}
+}
private void createCMaps() {
cmaps = new ArrayList();
@@ -626,6 +637,10 @@
return is_embeddable;
}
+public boolean isCFF() {
+ return isCFF;
+}
+
/**
* Read Table Directory from the current position in the
@@ -634,7 +649,22 @@
* as value.
*/
protected void readDirTabs(FontFileReader in) throws IOException {
-in.skip(4);// TTF_FIXED_SIZE
+ byte[] verBytes = new byte[4];
+ verBytes[0] = in.readTTFByte();
+ verBytes[1] = in.readTTFByte();
+ verBytes[2] = in.readTTFByte();
+ verBytes[3] = in.readTTFByte();
+ String version = new String(verBytes, "ISO-8859-1");
+ if (verBytes[1] == 0x01) {
+ System.out.println("Font is TrueType TTF format");
+ } else if (version.equals("OTTO")) {
+ System.out.println("Font is OpenType CFF format");
+ isCFF = true;
+ } else {
+ String msg = "Font does not appear to be either
TrueType or OpenType";
+ throw new IOException(msg);
+ }
+
int ntabs = in.readTTFUShort();
in.skip(6);// 3xTTF_USHORT_SIZE
Index: TTFDirTabEntry.java
===
RCS file: /home/cvspublic/xml-
fop/src/org/apache/fop/fonts/Attic/TTFDirTabEntry.java,v
retrieving revision 1.4.2.2
diff -w -u -r1.4.2.2 TTFDirTabEntry.java
--- TTFDirTabEntry.java 20 Sep 2003 21:48:18 - 1.4.2.2
+++ TTFDirTabEntry.java 8 Jan 2004 19:32:01 -
@@ -50,7 +50,8 @@
*/
package org.apache.fop.fonts;
-import java.io.IOException;
+import java.io.IOException;
import java.io.UnsupportedEncodingException;
+
class TTFDirTabEntry {
byte[] tag;
@@ -85,7 +86,18 @@
* " length: " + length +
* " name: " + new String(tag));
*/
-return new String(tag, "ISO-8859-1");
+ String tagStr = new String(tag, "ISO-8859-1");
+// System.err.println("tag='" + tagStr + "'");
+
+//System.out.println(this.toString());
+return tagStr;
}
+ public String getTagString() {
+ try {
+ return new String(tag, "ISO-8859-1");
+ } catch (UnsupportedEncodingException e) {
+ return this.toString(); // Should never happen.
+ }
+ }
}
Index: TTFReader.java
===
RCS file: /home
