Re: background-position-vertical and -horizontal
A log message is not good enough. That needs to throw an exception. It's a bug if IPD and BPD are not set IMO. Would you write test cases for all the possible combinations after adding the exception and before fixing the problems? I can help you there, if you like. On 25.08.2005 08:40:22 Manuel Mall wrote: The safety check in addBackground is already there. This is how I stumbled across it as it is triggered by one of the layout engine tests. I'll look into it as part of the whole percentage stuff I'm currently doing. On Thu, 25 Aug 2005 02:35 pm, Jeremias Maerki wrote: You are right. It seems like some calls to TraitSetter.addBackground() are issued before IPD and BPD of the area are set (list-block and list-item, for example). Yes, the call will need to be deferred until the BPD and IPD have been set on the area. A safety check in addBackground() will be a very good idea, too. You or me? :-) On 25.08.2005 05:14:04 Manuel Mall wrote: When setting a relative background position the positioning is relative to the size of the area the background is applied to. Currently the position calculation is done when the area is created, i.e. when the background trait is set. However, at that point in time fop may not know the bpd and ipd of the area in question. Therefore the calculated positioning will be wrong. Am I correct in saying that the logic needs to be changed to do that calculation (or even set the background trait) when the layout is completed for that area and not when the area is created in the layout process? Jeremias Maerki Manuel Jeremias Maerki
[OT] Do you know nabble.com?
I've just found in interesting link on [EMAIL PROTECTED] Do you know about http://www.nabble.com? http://www.nabble.com/Xml-Graphics-f307.html http://www.nabble.com/FOP-f309.html http://www.nabble.com/FOP---Dev-f352.html http://www.nabble.com/FOP---Users-f353.html Hierarchical list organization, cool. :-) And then you have really cool URLs like http://www.nabble.com/Number-of-Pages--n251174.html which directly point you to a particular thread. I like that. Jeremias Maerki
Re: background-position-vertical and -horizontal
Can do, but I'll get the percentage stuff more stable first. On Thu, 25 Aug 2005 02:48 pm, Jeremias Maerki wrote: A log message is not good enough. That needs to throw an exception. It's a bug if IPD and BPD are not set IMO. Would you write test cases for all the possible combinations after adding the exception and before fixing the problems? I can help you there, if you like. On 25.08.2005 08:40:22 Manuel Mall wrote: The safety check in addBackground is already there. This is how I stumbled across it as it is triggered by one of the layout engine tests. I'll look into it as part of the whole percentage stuff I'm currently doing. On Thu, 25 Aug 2005 02:35 pm, Jeremias Maerki wrote: You are right. It seems like some calls to TraitSetter.addBackground() are issued before IPD and BPD of the area are set (list-block and list-item, for example). Yes, the call will need to be deferred until the BPD and IPD have been set on the area. A safety check in addBackground() will be a very good idea, too. You or me? :-) On 25.08.2005 05:14:04 Manuel Mall wrote: When setting a relative background position the positioning is relative to the size of the area the background is applied to. Currently the position calculation is done when the area is created, i.e. when the background trait is set. However, at that point in time fop may not know the bpd and ipd of the area in question. Therefore the calculated positioning will be wrong. Am I correct in saying that the logic needs to be changed to do that calculation (or even set the background trait) when the layout is completed for that area and not when the area is created in the layout process? Jeremias Maerki Manuel Jeremias Maerki Manuel
Re: background-position-vertical and -horizontal
Manuel Mall wrote: The safety check in addBackground is already there. This is how I stumbled across it as it is triggered by one of the layout engine tests. Also note that the percentage handling in addBackground is a rough hack that doesn't work when expressions are used: 40% + 1pt. regards, finn
Re: background-position-vertical and -horizontal
OK thanks, another thing to look at - I am certainly not running out of work here, just the payment is lousy :-). On Thu, 25 Aug 2005 03:08 pm, Finn Bock wrote: Manuel Mall wrote: The safety check in addBackground is already there. This is how I stumbled across it as it is triggered by one of the layout engine tests. Also note that the percentage handling in addBackground is a rough hack that doesn't work when expressions are used: 40% + 1pt. regards, finn Manuel
Re: .htaccess file for the old FOP website
Jeremias Maerki schrieb: Very weird. Look here: http://xml.apache.org/fop GET /fop HTTP/1.1 Host: xml.apache.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 [..] HTTP/1.x 301 Moved Permanently Date: Thu, 25 Aug 2005 06:24:28 GMT Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7a DAV/2 SVN/1.2.0-dev Location: http://xml.apache.org/fop/ [..] And this should give another redirect to http://xmlgraphics.apache.org (and it does so for me) Anyway, I've removed the trailing slashes in the .htaccess file, hopefully this will fix it. -- Christian
Re: svn commit: r240012 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render: pdf/PDFRenderer.java ps/PSRenderer.java
Jeremias,
Just in case you intended to do any improvement there: the FOrayFont integration
may bring some facilities in this area. At least the handling will be different,
so I don't think it's worth working on this before the integration is done. So
please leave it as is for now. Thanks!
I've finished reading the huge amount of mails that have been written to this
list during August, getting back to work now.
Regards,
Vincent
[EMAIL PROTECTED] a écrit :
Author: jeremias
Date: Thu Aug 25 00:28:27 2005
New Revision: 240012
URL: http://svn.apache.org/viewcvs?rev=240012view=rev
Log:
Kerning is currently not supported by the layout engine, so disable it for PDF
and add a TODO item for PS.
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFRenderer.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/PSRenderer.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFRenderer.java
URL:
http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFRenderer.java?rev=240012r1=240011r2=240012view=diff
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFRenderer.java
(original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pdf/PDFRenderer.java
Thu Aug 25 00:28:27 2005
@@ -1187,7 +1187,9 @@
boolean kerningAvailable = false;
Map kerning = fs.getKerning();
if (kerning != null !kerning.isEmpty()) {
-kerningAvailable = true;
+//kerningAvailable = true;
+//TODO Reenable me when the layout engine supports kerning, too
+log.warn(Kerning support is disabled until it is supported by the
layout engine!);
}
int l = s.length();
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/PSRenderer.java
URL:
http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/PSRenderer.java?rev=240012r1=240011r2=240012view=diff
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/PSRenderer.java
(original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/PSRenderer.java Thu
Aug 25 00:28:27 2005
@@ -25,6 +25,7 @@
import java.io.OutputStream;
import java.util.Iterator;
import java.util.List;
+import java.util.Map;
// FOP
import org.apache.avalon.framework.configuration.Configuration;
@@ -713,7 +714,16 @@
handleIOTrouble(ioe);
}
}
-//paintText(rx, bl, , f);
+
+boolean kerningAvailable = false;
+Map kerning = tf.getKerningInfo();
+if (kerning != null !kerning.isEmpty()) {
+//kerningAvailable = true;
+//TODO Fix me when kerning is supported by the layout engine
+log.warn(Kerning info is available, but kerning is not yet implemented
for
++ the PS renderer and not currently supported by the layout
engine.);
+}
+
String text = area.getTextArea();
beginTextObject();
writeln(1 0 0 -1 + gen.formatDouble(rx / 1000f)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r240012 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render: pdf/PDFRenderer.java ps/PSRenderer.java
No intentions to fix kerning right now. I just documented the problem. I hope you had good holidays! On 25.08.2005 11:38:23 Vincent Hennebert wrote: Jeremias, Just in case you intended to do any improvement there: the FOrayFont integration may bring some facilities in this area. At least the handling will be different, so I don't think it's worth working on this before the integration is done. So please leave it as is for now. Thanks! I've finished reading the huge amount of mails that have been written to this list during August, getting back to work now. Jeremias Maerki
DO NOT REPLY [Bug 35940] - 1.0dev differences to 0.20.5
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35940. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35940 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 14:20 --- Fixed, thanks for signalling this bug! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36356] New: - Problem with column balancing in multi-column layout
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36356. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36356 Summary: Problem with column balancing in multi-column layout Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] The attached xml (process like other layout engine tests) seems to exhibit a problem with the column balancing. The 6 lines in the first block are distributed over 2 columns only. The moment the margin=5% is removed on the block the 6 lines are distributed over 3 columns. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36356] - Problem with column balancing in multi-column layout
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36356. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36356 --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 14:33 --- Created an attachment (id=16195) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16195action=view) xml sample to demonstrate the problem -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
RE: Relative font weights and font selection
Victor Mote wrote (August 8): Manuel Mall wrote: Regarding the bolder, lighter issue and the general font selection I looked at the pre-patch for FOrayFont adaptation to Fop (http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and concluded that meddling with the font selection system will interfere with the FOray font integration and that the FOray font system has addressed most of the font selection issues any way (not sure about the bolder, lighter bits though). I will therefore back-off from that line of work and wait for the FOray font integration to complete, assuming that it is still going ahead. Sorry to be so slow responding. I think Vincent is taking August off, but is still working on the font integration work. Manuel and I have had an off-line conversation about the bolder/lighter issue, and I think we will need to improve both the interface and the implementation to handle this and the similar issues for font-stretch. I'll work on that in the next week or two. First, sorry to be so slow. I can finally get to all my tools again. I am ignoring font-stretch for now. I am unclear whether it works similarly to font-weight, or whether it is totally resolvable in the FO Tree. Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C) removes font-stretch entirely!!??!! For font-weight, there seems to be some ambiguity in the standard(s). There are two possibilities, and neither CSS 2.1 nor XSL-FO seem to resolve the matter: 1. Apply bolder and lighter to the inherited font to compute a weight that is applied to the selected font. 2. Select the font, inheriting the weight from the inherited font, then applying bolder and lighter to that weight. In order to move forward, I suggest the addition of the following methods in org.axsl.font.Font: public byte nextBolderWeight(); public byte nextLighterWeight(); public org.axsl.font.Font nextBolderFont(); public org.axsl.font.Font nextLighterFont(); This will allow the client application (FOP) to use whichever algorithm it thinks is appropriate. The bad news is that this ties each registered font to exactly one font-family, something I was hoping to avoid. There is another area complexity in font selection that has not yet been addressed, so I pose it here to Vincent and Manuel especially, and to any others who wish to comment. The whole issue of whether the Font has a glyph for the character(s) has not yet been addressed. The best idea I have for this is as follows: 1. Add a char to the signature of org.axsl.font.FontServer.selectFont. This char represents the first char of the text for which the font is being selected. This allows the selection process to pass by a font-family if it cannot paint the character. 2. Add the following method to org.axsl.font.Font: /** * Examines each character in string to ensure that a glyph exists in the font for that * character. If a character has no glyph in the font, the character's index in string * is returned. * @return The index in string of its first character for which no glyph exists in this * font. If all characters in the string have glyphs in this font, -1 is returned. */ public int unavailableChar(String string); Add also an overridden version of this method with char[] as the parameter. Between these two, I think an application should be able to efficiently subdivide a chunk of text based on the various fonts that may need to be used to process it. Comments on any of this are very welcome. I had hoped to defer some of these font selection issues for a while yet, and you guys are frankly ahead of me in needing to resolve them, so I will be glad to react to those who may have thought it through more than I have. BTW, while very briefly looking at parts of the FOray/aXSL font selection code I noticed at least one instance where it relied on a JDK 1.4 API call. Not quite what we want for FOP I believe but I am sure easy to fix for Victor. Yes, we should be able to get a 1.3 solution for this. BTW, FOray is theoretically dependent on 1.4. However, I don't know that there are any 1.4 dependencies in the font code. I have removed the 1.3 dependency noted in aXSL. There may be others that need to be addressed to retrofit for 1.3 use. Victor Mote
FOTree Table FOs -- definitely non-urgent, just probing...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Has anyone ever thought about introducing an abstract class for table-related FOs, say TableFObj, that would be extended by all those FOs? It just occurred to me that there are: a) the border-precedences that are applicable only to those types of FO (=all of them) b) the borders themselves that behave differently when specified on table-FOs in case of collapse(-with-precedence) I just got to thinking that an abstract superclass could be used to bundle some of that functionality. (For example: binding the border-*-precedence properties. Right now, the related code has to be repeated in at least five classes...) Although currently I don't see a compelling reason to do so, it might be an idea that's worth revisiting later on... I'll keep it on my personal list of ideas to consider, unless anyone has strong objections against such a move. WDYT? Cheers, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDDh/YyHTbFO9b8aARAjZOAKCmnhiY8hMUg0QZcfyGgxCeK7xD4QCgv9gZ Xh69Hymwn8k3T1P4RPgD/5Y= =cI/s -END PGP SIGNATURE-
Re: JAXG snapshot available (was: Re: API discussion (revived))
Jeremias, It is a good package. I have a few remarks. 1. At some point I wanted it to be possible to set input and output types on the Factory. In that way it would be possible to write a factory implementation which knows about several of the processing engines, and depending on the input and output types (and some user configuration, at the discretion of the factory implementation) could choose the best engine, e.g. JFOR for fo to rtf, FOP head for fo to all other, Batik for SVG to other. But that would introduce input type dependence into the code. Currently the following code: XGProcessorFactory factory = XGProcessorFactory.newInstance(); XGProcessor processor = factory.newXGProcessor(); Source src = new StreamSource(new File(args[0])); XGResult res = new StreamXGResult(application/pdf, new File(args[1])); processor.process(src, res); together with the appropriate value of the system property can be used to process both FO and SVG, with the engine of choice by the invoker. 2. I am a bit suprised that you use a specific factory implementation in your examples, and not the engine agnostic newInstance method. This is counter to the goal of engine agnostic code. This made me think that perhaps another goal is more important: This is a framework that allows one to access each engine through the same interface. It does so by writing adapters between the defined interface and the engines. Viewed this way, the reference implementation is not just that. It is the essential part of your package, viz. the set of adapters. 3. The interface is not limited to XML Graphics applications. It is suitable for any engine that exposes a SAXResult interface, or can be made to expose such an interface by an adapter. I hope these thoughts make sense. Regards, Simon On Mon, Aug 22, 2005 at 12:23:45PM +0200, Jeremias Maerki wrote: I've cleaned up JAXG and published it on my website: http://www.jeremias-maerki.ch/dev/jaxg/ Comments are welcome. Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
