path of checkstyle.header
In checkstyle-4.0.xml I need to set
property name=headerFile value=${samedir}/checkstyle.header/
instead of
property name=headerFile value=checkstyle.header/
to get the Eclipse Checkstyle plugin to find the header. Do I do
something wrong, or can I safely commit this change?
Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: 4.3.2 Overconstrained space-specifiers
Jeremias Maerki wrote: You will have seen that I've been working on overconstrained documents. 5.3.4 Overconstrained Geometry is more or less implemented, so now I need to have a look at 4.3.2 which proves quite difficult to understand. At least I can't make much sense of it ATM. [...] If anyone has an idea what rule 4 in 4.3.1 or the section 4.3.2 is about I'd love to read your thoughts. Otherwise, I will run this through the XSL editors list. I always thought (probably wrongly) these sections of the spec refer to the page regions, maybe because of the property display-align, and more as a way to formally justify what is usually done than as prescribing some particular behaviour. To be more clear (I hope :-)): region viewports usually have a well-known height (unless there is only a single page whose height is unbounded); their area children don't always fill them completely. The content areas are placed at the top / center / bottom of the viewport according to the value of display-align: but, as these extra spaces may be in contrast with the space properties of the first and last child areas, we need, from a formal point of view, a rule saying that we are allowed to do this, otherwise the specs would be inconsistent. In other words, I always read these rules as: spaces added ad the top / bottom of a page to implement display-align have greater precedence than space-before or space-after traits of the child areas. According to me, rule 4 should state something like this: the maximum value of the space-specifier is set to the difference between the containing height and the content height. Don't know if this makes any sense ... Regards Luca
Re: Kerning
Starting from your final summary: Manuel Mall wrote: IMO FOP should limit itself to: a) Use kerning only for consecutive characters within the same fo Ok, but more on this later in this message ... b) Limit itself to the kerning information in the font Ok c) Only apply kerning if the letter-spacing property has the value normal (and the font supports it) Isn't this condition too strong? I see kerning as an extra space, something that is added to the letter spacing, not something that replaces it. A simple example with our kerning couple AV: a) at the moment kerning is not implemented, so with normal letter-spacing the space between A and V seems bigger than the space between I and L, for example; b) we implement kerning, so the space between A and V is reduced and it visually looks like the space between I and L; c) what if we have a negative letter-spacing? if we don't apply kerning any more, we go back to a): the space between A and V would seem bigger than the space between I and L. In other words: if the kerning value stored in the font is correct, it should always be added to the letter spacing: it would make the characters overlap only when the letter-spacing alone would make normal characters overlap, and in this case this should be considered the desired output. In the end XSL-FO has the letter-spacing property which users (and programs generating XSL-FO) can use to adjust kerning. A little doubt concerning letter spaces: at the moment, a letter space is assigned to the preceding character. Is this correct? I don't remember any section in the specs stating about the ownership of letter spaces ... I think that everything is simpler, from the point of view of both users and implementors, if each letter space is owned by the preceding (or following) formatting object, but this does not mean it is what the specs require! An example: if we have the text WORD where each letter is a fo:character, the first three fo:character ATM have a letter space each, and the fourth has none. All is ok as long as the fo:characters have no (or equal) letter-spacing, but what if each fo:character has a different letter-spacing property the ouput is different according to the fo:characters controlling letter spaces. Regards Luca
Re: path of checkstyle.header
I haven't found anything about ${samedir}, but if the same also works
from the Ant build then yes, it should work.
On 09.12.2005 14:23:30 Simon Pepping wrote:
In checkstyle-4.0.xml I need to set
property name=headerFile value=${samedir}/checkstyle.header/
instead of
property name=headerFile value=checkstyle.header/
to get the Eclipse Checkstyle plugin to find the header. Do I do
something wrong, or can I safely commit this change?
Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Jeremias Maerki
Re: 4.3.2 Overconstrained space-specifiers
Thanks, Luca. It does make sense but I'm having trouble mapping your interpretation to what is written in the spec. I wonder: Do you agree with me that my second example wouldn't be affected by the rules described in 4.3.2? Anyway, I think I'm going to let this rest and instead concentrate on detecting overflow situations. After all, this stuff here seems pretty exotic. On 09.12.2005 14:40:01 Luca Furini wrote: Jeremias Maerki wrote: You will have seen that I've been working on overconstrained documents. 5.3.4 Overconstrained Geometry is more or less implemented, so now I need to have a look at 4.3.2 which proves quite difficult to understand. At least I can't make much sense of it ATM. [...] If anyone has an idea what rule 4 in 4.3.1 or the section 4.3.2 is about I'd love to read your thoughts. Otherwise, I will run this through the XSL editors list. I always thought (probably wrongly) these sections of the spec refer to the page regions, maybe because of the property display-align, and more as a way to formally justify what is usually done than as prescribing some particular behaviour. To be more clear (I hope :-)): region viewports usually have a well-known height (unless there is only a single page whose height is unbounded); their area children don't always fill them completely. The content areas are placed at the top / center / bottom of the viewport according to the value of display-align: but, as these extra spaces may be in contrast with the space properties of the first and last child areas, we need, from a formal point of view, a rule saying that we are allowed to do this, otherwise the specs would be inconsistent. In other words, I always read these rules as: spaces added ad the top / bottom of a page to implement display-align have greater precedence than space-before or space-after traits of the child areas. According to me, rule 4 should state something like this: the maximum value of the space-specifier is set to the difference between the containing height and the content height. Don't know if this makes any sense ... Regards Luca Jeremias Maerki
MathML for fop-trunk
Hello all, some time ago my colleague announced that we are working on MathML implementation for FOP. Our work is based on the JEuclid library. Now we completed code review to comply with ASF code requirements. Our results are available from CVS at :pserver:[EMAIL PROTECTED]:/cvsroot/jeuclid (http://sourceforge.net/projects/jeuclid/). Among MathML feature we made several additional features for fop-0.20.4. These features are also included into test/first-demo and consists of - to embed PDF's; - to have bold, italic styles for TTF Unicode fonts (namely Arial Unicode MS). Now we are thinking of integrating these features into fop-trunk. Please, have a look whether our results is satisfactory to become part of fop or xmlgraphics at ASF. Any of the comments are welcome. There are also several issues, that we would like to ask here to make resolve them in general way: 1. How to configure font to render MathML. Most of the font does not contain enough mathematical symbols to render complex mathematical formulas. At the moment we have constant pointing to Arial Unicode MS (as mostly completed Unicode font). We were tried to make support of another font but stop this activity after finding out that (in this font Integral symbol is missing but Top Half Integral and Bottom Half Integral are present). We need an idea how we could handle such situations in a general way. 2. When rendering MathML we used awt.Font class, which is not accessible on the Unix boxes without X-server installed. The awt.Font class is used to get font size for proper position of the upper and lower indexes and so on. Are there any chance, that we could re-use Fop generated metrics? Where we could start look at that? Taking into consideration these to issues, I guess, that JEuclid is still to young, however, it is already powerful enough to start look at it. -- Best regards, Gennadiy Tsarenkov
Re: MathML for fop-trunk
Hi Gennadiy, good to hear that things are going well in MathML land. More comments inline... On 09.12.2005 16:15:17 Gennadiy Tsarenkov wrote: Hello all, some time ago my colleague announced that we are working on MathML implementation for FOP. Our work is based on the JEuclid library. Now we completed code review to comply with ASF code requirements. Our results are available from CVS at :pserver:[EMAIL PROTECTED]:/cvsroot/jeuclid (http://sourceforge.net/projects/jeuclid/). Among MathML feature we made several additional features for fop-0.20.4. These features are also included into test/first-demo and consists of - to embed PDF's; - to have bold, italic styles for TTF Unicode fonts (namely Arial Unicode MS). Now we are thinking of integrating these features into fop-trunk. Please, have a look whether our results is satisfactory to become part of fop or xmlgraphics at ASF. Any of the comments are welcome. I'll try to find time to have a look in the next few days. There are also several issues, that we would like to ask here to make resolve them in general way: 1. How to configure font to render MathML. Most of the font does not contain enough mathematical symbols to render complex mathematical formulas. At the moment we have constant pointing to Arial Unicode MS (as mostly completed Unicode font). We were tried to make support of another font but stop this activity after finding out that (in this font Integral symbol is missing but Top Half Integral and Bottom Half Integral are present). We need an idea how we could handle such situations in a general way. I guess you have to provide the ability to specify a list of prioritized fonts (like in the XSL-FO font-family property) as an extension attribute on the MathML root element. With this list you could check each font in the list if it provides the character you're looking for. The font subsystem of FOP supports querying a FOP is a specific glyph is available in a font. See hasChar(char) in SinglyByteFont and MultiByteFont in the fonts package of FOP Trunk. I don't know if AWT provides something similar. 2. When rendering MathML we used awt.Font class, which is not accessible on the Unix boxes without X-server installed. The awt.Font class is used to get font size for proper position of the upper and lower indexes and so on. Are there any chance, that we could re-use Fop generated metrics? Where we could start look at that? In FOP Trunk, the fonts package. Everything's there. However, currently Vincent Hennebert works on integrating the font subsystem from FOray which will be a little different. It may make sense not to rush into anything too quickly here. Vincent implied that it wouldn't take too long until he has something ready if I remember correctly. On the other side, relying on AWT's font subsystem for MathML isn't that bad. People have to set up one of the three work-arounds for headless systems anyway. Batik needs it, too. Taking into consideration these to issues, I guess, that JEuclid is still to young, however, it is already powerful enough to start look at it. Let's start where we can. You can certainly start with the FOP extension for the new JEuclid. It doesn't have to be perfect at first. I'll try to find time to see what is now there. I'm sure we'll figure out how best to approach all this. Jeremias Maerki
RE: Kerning
Hi Luca. Its been over 15 years since I did any kerning, but, from what I remember, kerning isn't just left or right, its also up and down (and possibly other transforms/alterations for all I know). Consider the kerned symbols in the LATeX logo. The A is raised and snuggled between the L and the T. I know that this is a special case, however, its worth verifying that the only spacing differences for all kerns are left/right. I seem to remember that some characters (small i or j come to mind) lose their dots in certain circumstances as well - that may not be kerning, though - I don't remember, its been 15 years :-) All of this would be from the LATeX manual and related documentation (MetaFont?), of which I don't have handy. Thanks. Shannon Mann -Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Sent: Friday, December 09, 2005 8:42 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Kerning Starting from your final summary: Manuel Mall wrote: IMO FOP should limit itself to: a) Use kerning only for consecutive characters within the same fo Ok, but more on this later in this message ... b) Limit itself to the kerning information in the font Ok c) Only apply kerning if the letter-spacing property has the value normal (and the font supports it) Isn't this condition too strong? I see kerning as an extra space, something that is added to the letter spacing, not something that replaces it. A simple example with our kerning couple AV: a) at the moment kerning is not implemented, so with normal letter-spacing the space between A and V seems bigger than the space between I and L, for example; b) we implement kerning, so the space between A and V is reduced and it visually looks like the space between I and L; c) what if we have a negative letter-spacing? if we don't apply kerning any more, we go back to a): the space between A and V would seem bigger than the space between I and L. In other words: if the kerning value stored in the font is correct, it should always be added to the letter spacing: it would make the characters overlap only when the letter-spacing alone would make normal characters overlap, and in this case this should be considered the desired output. In the end XSL-FO has the letter-spacing property which users (and programs generating XSL-FO) can use to adjust kerning. A little doubt concerning letter spaces: at the moment, a letter space is assigned to the preceding character. Is this correct? I don't remember any section in the specs stating about the ownership of letter spaces ... I think that everything is simpler, from the point of view of both users and implementors, if each letter space is owned by the preceding (or following) formatting object, but this does not mean it is what the specs require! An example: if we have the text WORD where each letter is a fo:character, the first three fo:character ATM have a letter space each, and the fourth has none. All is ok as long as the fo:characters have no (or equal) letter-spacing, but what if each fo:character has a different letter-spacing property the ouput is different according to the fo:characters controlling letter spaces. Regards Luca - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: MathML for fop-trunk
2. When rendering MathML we used awt.Font class, which is not accessible on the Unix boxes without X-server installed. The awt.Font class is used to get font size for proper position of the upper and lower indexes and so on. Are there any chance, that we could re-use Fop generated metrics? Where we could start look at that? In FOP Trunk, the fonts package. Everything's there. However, currently Vincent Hennebert works on integrating the font subsystem from FOray which will be a little different. It may make sense not to rush into anything too quickly here. Vincent implied that it wouldn't take too long until he has something ready if I remember correctly. Right. My patch should be available in a few days now. You may start to have a look at the aXSL web page [1], and especially the axslFont module. This is the interface that will be available to users of the font sub-system. I suggest you download aXSL through the CVS repository and just build the javadoc to see what will be available to you (the most important interfaces are Font and FontUse). If you decide to look at aXSL and have any questions, please ask them on the aXSL mailing-list [2], which will be more appropriate than this list. I'm glad to see that MathML support is coming along. Thank you, Vincent [1] http://www.axsl.org [2] http://sourceforge.net/mail/?group_id=123259
