This patch adds support for image plugins to define their baseline-shift. Please note: This may break existing image plugins, but recompilaton should be sufficient.
Created attachment 20424 [details] baselineshift patch The actual patch file
Some other comments while I am at it: External graphic dimensions are specified in millipoints (int), where as inline-graphics are specified in pts (float). I have followed the same pattern for this patch, but find it quite inconsitent.
(In reply to comment #2) Hi Max, Thanks for your patch. However, I'm slightly reluctant to apply it as is. I have a few questions: - I can understand the need for an intrinsic baseline-shift for images, especially if the image represents, say, a mathematical formula... That said, in plain FO I think I would use the alignment-adjust property (XSL-FO 1.1, 7.14.1). Now I easily understand that it would be difficult to store this information separately from the image but, still, shouldn't the image have an intrinsic alignment-adjust instead? The description of alignment-adjust says that this property especially applies to images which lack of a baseline-table. Whereas baseline-shift recreates a whole baseline-table for the area. Granted, this doesn't change many things but I think it would be more consistent. - IIC, the intrinsic baseline-shift may only be a length? Isn't that limiting? If the image is scaled for whatever reason, then the length no longer makes sense. A percentage would probably be more robust. Especially if it's expressed in terms of the image's height. And guess what, that's exactly the case with alignment-adjust. BTW, percentages are the reason why the other FOs return a Length object for their baseline-shift. > Some other comments while I am at it: > > External graphic dimensions are specified in millipoints (int), where > as inline-graphics are specified in pts (float). I have followed the > same pattern for this patch, but find it quite inconsitent. I'm not sure of what you are referring to? For both ExternalGraphic and InstreamForeignObject the intrinsic dimensions are specified in millipoints. WDYT? Thanks, Vincent
Vincent, 1) you are right, alignment-adjust seems a better attribute to use. I did some tests with the foprep application (JEuclids MathML in FO preprocessor), and using percentage values here seems to work fine. 2) I also have the feeling that I need to set "alignment-baseline" to "alphabetic" as well (in the case of Math, but have it settable by the plugin), but i am not sure about this, as I have no experience with non-latin languages, and even less with non-latin languages and Math. 3) If i read the spec correctly, the values of baseline-shift and alignment-adjust are in the opposite direction: So far I had to use a negative baseline-shift, and i should use a positive alignment-adjust (my understanding of the spec). However, during my tests I had to use a negative alignment-adjust, suggesting that fop has a bug here. This needs further investigation. 4) The pt. vs. millipoint: What I was referring to is: org/apache/fop/fo/flow/InstreamForeignObject.java and org/apache/fop/fo/XMLObj, which store dimensions using float in pt., where as org/apache/fop/fo/flow/ExternalGraphic.java stores dimensions in "int" in millipoints. Both are fine with me, however, I think this is inconsistent and should be unified rather sooner than later. However, changing this will definitely break plugins, so it should be done as soon as possible!
and yet another question: 5) when overwriting alignment adjust, there are two possibilities: a) Retrieve set (from .fo file) alignment adjust, and add image-intrinsic alignment-adjust b) retrieve set alignment adjust. If it is auto (default if not set), then use image-intrinsic alignment-adjust, otherwise use the one given from the user I think b makes more sense, as the user will be able to explicitly overwrite the automatic calculated alignment adjust. However, this behavior may be a little irritating, as specifying a value at all (e.g. 0pt instead of auto) will already make a difference.
Created attachment 20475 [details] Updated patch which uses alignment-adjust
If updated the patch to use alignment-adjust instead of baseline-shift, as this is indeed a better solution. in reply to my own comments: 1) done 2) this defaults to baseline, which is good enough for my use. 3) I misread the spec. It was just unclearly written. 4) The issue still stands, for the patch I've used length exclusively, which does not have this problem 5) Strategy b) is used.
Looked OK to me, so patch applied. see: http://svn.apache.org/viewvc?view=rev&rev=554423 Thanks for the contribution!
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed