Re: block rendering problem with 0.20.5rc2
Sorry, I didn't see it. It's not particularly easy to keep up with all the known defects. As to mixing block elements and text, it may not be the best style, but from our point of view is more practical -- the old form vs function debate and in my case function wins every time. Thanks for the reference. I'll try not to bore you in the future. matthew l. avizinis J.Pietschmann wrote: Matthew L. Avizinis wrote: The following fo apparently causes the last line of text from the text area of the parent fo:block to be rendered twice, once before the child fo:block and once after it. See Bugzilla #17472. Either don't mix block elements and text (bad style anyway), or get CVS code. This is mentioned a few times a week meanwhile, and it gets bring. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOPAltDesignIntegration
Fopdevs, Have at last started work on the Wiki page, named above. It's far from complete yet. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18292] - 24 bit PNG not displayed correctly
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=18292. 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=18292 24 bit PNG not displayed correctly --- Additional Comments From [EMAIL PROTECTED] 2003-03-25 20:36 --- I am using 20.4 with JAI. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
vmote 2003/03/25 15:34:11 Modified:src/codegen foproperties.xml src/java/org/apache/fop/fo FOText.java FObjMixed.java PropertyManager.java TextInfo.java src/java/org/apache/fop/fo/pagination Root.java Log: Add support for text-transform. Revision ChangesPath 1.37 +7 -1 xml-fop/src/codegen/foproperties.xml Index: foproperties.xml === RCS file: /home/cvs/xml-fop/src/codegen/foproperties.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- foproperties.xml 29 Nov 2002 23:18:51 - 1.36 +++ foproperties.xml 25 Mar 2003 23:34:10 - 1.37 @@ -1277,7 +1277,13 @@ property nametext-transform/name inheritedtrue/inherited -datatypeToBeImplemented/datatype +datatypeEnum/datatype +enumeration + value const=NONEnone/value + value const=CAPITALIZEcapitalize/value + value const=UPPERCASEuppercase/value + value const=LOWERCASElowercase/value +/enumeration defaultnone/default /property property 1.2 +323 -17 xml-fop/src/java/org/apache/fop/fo/FOText.java Index: FOText.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOText.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- FOText.java 11 Mar 2003 13:05:19 - 1.1 +++ FOText.java 25 Mar 2003 23:34:11 - 1.2 @@ -3,34 +3,34 @@ * *The Apache Software License, Version 1.1 * - * + * * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. - * + * * Redistribution and use in source and binary forms, with or without modifica- * tion, are permitted provided that the following conditions are met: - * + * * 1. Redistributions of source code must retain the above copyright notice, *this list of conditions and the following disclaimer. - * + * * 2. Redistributions in binary form must reproduce the above copyright notice, *this list of conditions and the following disclaimer in the documentation *and/or other materials provided with the distribution. - * + * * 3. The end-user documentation included with the redistribution, if any, must *include the following acknowledgment: This product includes software *developed by the Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, if *and wherever such third-party acknowledgments normally appear. - * + * * 4. The names FOP and Apache Software Foundation must not be used to *endorse or promote products derived from this software without prior *written permission. For written permission, please contact *[EMAIL PROTECTED] - * + * * 5. Products derived from this software may not be called Apache, nor may *Apache appear in their name, without prior written permission of the *Apache Software Foundation. - * + * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE @@ -42,12 +42,12 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * + * * This software consists of voluntary contributions made by many individuals * on behalf of the Apache Software Foundation and was originally created by * James Tauber [EMAIL PROTECTED]. For more information on the Apache * Software Foundation, please see http://www.apache.org/. - */ + */ package org.apache.fop.fo; // Java @@ -60,15 +60,20 @@ import org.apache.fop.layoutmgr.TextLayoutManager; import org.apache.fop.apps.StructureHandler; import org.apache.fop.fo.properties.WhiteSpaceCollapse; +import org.apache.fop.fo.flow.Block; +import org.apache.fop.fo.pagination.Root; +import org.apache.fop.fo.properties.TextTransform; /** * A text node in the formatting object tree. * - * Modified by Mark Lillywhite, [EMAIL PROTECTED] * Unfortunately the BufferManager implementatation holds * onto references to the character data in this object * longer than the lifetime of the object itself, causing * excessive memory consumption and OOM errors. + * + *
cvs commit: xml-fop/src/java/org/apache/fop/fo FOText.java
vmote 2003/03/25 16:00:17
Modified:src/java/org/apache/fop/fo FOText.java
Log:
Eliminate array looping if text-transform is NONE for a probable performance benefit.
Revision ChangesPath
1.3 +3 -0 xml-fop/src/java/org/apache/fop/fo/FOText.java
Index: FOText.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/FOText.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FOText.java 25 Mar 2003 23:34:11 - 1.2
+++ FOText.java 26 Mar 2003 00:00:16 - 1.3
@@ -252,6 +252,9 @@
* text-transform property.
*/
private void textTransform() {
+if (textInfo.textTransform == TextTransform.NONE) {
+return;
+}
for (int i = 0; i ca.length; i++) {
ca[i] = charTransform(i);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOText constructor (trunk)
Keiron Liddle wrote: Jeremias Maerki wrote: Anyway, may I ask for the reason that you want to do that? Sure. I am trying to port some code I wrote to implement text-transform for the maintenance branch over to the trunk. One of the key things there is to tie together all FOText objects that are part of the same Block, so that word boundaries are respected regardless of the markup. The way I implemented this was to keep finding ancestors until I came to a Block. I can't do that without the reference to the parent. It is not a high priority thing, but I am trying to finish up all of the stuff I started in the maintenance branch. Should've read this earlier. This sounds more like a layout thing. If you are going to find complete words to do some manipulation then I would suggest taking a look at the getWordChars method in the layout managers. This is used to gather together all strings in from different layout managers, eg. when there is a inline fo. At the moment it is meant for hyphenation. The exact implementation for this may change but that is the general idea. I looked at the layout classes did not find what I needed. I decided to go ahead implement the text-transform in FOText, and have committed that change. There is a test document that I placed in the repository some time ago, and the committed code handles all of those tests fine, including Joerg's nested wrappers. Oleg actually wrote quite a bit of this code. The only insight I added was where to run it how to tie the FOText objects together, and as Keiron has pointed out, there may yet be a better place to do this. If so, I will adjust it later. Other issues: 1. I use a static variable in FOText (lastFOTextProcessed). I do not know of a good way around this until we resolve where to put document- and session- level stuff. This particular variable belongs to the document. I thought about using the fo.Root object for this, and that may be a good idea. However, you either need to pass the reference to it around, or compute it (by going up the fo tree until you find it). Jeremias I got bogged down in how this should work, and we probably need to revisit it. I haven't been able to spend enough time with Avalon yet to see how it helps us with this. 2. There may be some i18n issues. All of my testing has been for English. The actual conversion all uses the Java routines, and I don't expect any trouble there. The tricky stuff is how to define where a word starts, and that may require some future work. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Development/Redesign tabs
I made some decent progress today on getting my head into the trunk code, and to document some of what I have learned. I am still confused by the Development and Redesign tabs. At first, I thought that maybe Development was for those who might be developing on the maintenance branch, and Redesign for those on the trunk, but the title to the index document under Development seems to belie that. I see that we have some problems with the left nav bar that result from our directory structure. For example, first click http://xml.apache.org/fop/design/index.html, then click on the tab entitled Understanding, and watch the left nav bar change, which you would think it should not. Perhaps we made the two tabs to ease that problem? Assuming that I can find the Forrest solution to that problem, is there any objection to merging these two tabs into one entitled Development? Hi Victor, The original idea of the development was for user documentation for the current development. So it can be updated as the API and other such details are changed. For example with the faq, it had some different information on things such as text in SVG. Maybe it would be better to only have the new information there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Development/Redesign tabs
Keiron Liddle wrote: The original idea of the development was for user documentation for the current development. So it can be updated as the API and other such details are changed. If user documentation means developer documentation, and current development means maintenance branch development, then I think I understand. That would make the redesign tab be for the new development. If that is what we want, then I'll go to work on making that more clear. For example with the faq, it had some different information on things such as text in SVG. Maybe it would be better to only have the new information there. With regard to the faq, I just last night sliced out nearly all of the contents of the dev/faq.xml file. As far as I could tell, it was a duplicate of an old version of the faq.xml. Those changes are not reflected on the site yet (I have emailed Jeff to try to find out why not). I don't care a lot about whether we have 1 or 2 developer tabs -- I just want to clarify what they are, not only so that I know what to put where, but also so that the web site users understand what they are seeing. It is confusing enough to have two branches of development, but to have our documentation mixed up or unclear is a serious problem. A case could be made that we don't want a developer tab for the maintenance branch, because we don't really want anyone developing for it. I kind of thought that was what was going on when I saw the index for it with the title FOP 1.0 development. I propose the following for a 3-tab structure (I am not ignoring the Alt Design tab, it just isn't affected by this): Home Release Development 1.0 Development If you prefer to combine the developer doc, then: Home Development Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Development/Redesign tabs
With regard to the faq, I just last night sliced out nearly all of the contents of the dev/faq.xml file. As far as I could tell, it was a duplicate of an old version of the faq.xml. Those changes are not reflected on the site yet (I have emailed Jeff to try to find out why not). It wasn't quite a duplication of the old version. So where should the new/updated information be put? It should be put somewhere so the information can be updated as we a\go and not be lost while still have the old version available. I don't care a lot about whether we have 1 or 2 developer tabs -- I just want to clarify what they are, not only so that I know what to put where, but also so that the web site users understand what they are seeing. It is confusing enough to have two branches of development, but to have our documentation mixed up or unclear is a serious problem. A case could be made that we don't want a developer tab for the maintenance branch, because we don't really want anyone developing for it. I kind of thought that was what was going on when I saw the index for it with the title FOP 1.0 development. I propose the following for a 3-tab structure (I am not ignoring the Alt Design tab, it just isn't affected by this): Home Release Development 1.0 Development If you prefer to combine the developer doc, then: Home Development Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Drawing images with PDFDocumentGraphics2D
How can I obtain an "java.awt.ImageObserver" that I can pass to one of the "drawImage" methods of PDFDocumentGraphics2D? Example: pdfgen = new PDFDocumentGraphics2D(true,System.out,800,1100); ... pdfgen.drawImage(img,100,100,50,50,imgObserver); With a pure AWT application, I would passthejava.awt.Panel whose "paint" methodinvokes"drawImage". But with PDFDocumentGraphics2D, I don't have such a Panel object. Even if I create a surrogate one, the resulting PDF will not have the images in it. What can act as the "ImageObserver"? Thanks, Julio Lerm Chicago, IL
