Bug report for Fop [2009/09/27]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 3824|New|Blk|2001-09-25|MIF option with tables| | 5010|New|Enh|2001-11-21|Better error reporting needed | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Type 1 CID fonts are not supported| | 8003|New|Maj|2002-04-12|FopImageFactory never releases cached images | | 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende| | 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code | |12610|New|Enh|2002-09-13|[PATCH] onLoad Action for PDF documents or how to | |14356|New|Nor|2002-11-07|*NOT* embedding TrueTypeFont in PDF causes Acrobat| |16713|New|Nor|2003-02-03|Hyphenation error in tables | |17369|New|Nor|2003-02-25|Footnote duplication | |17380|New|Nor|2003-02-25|Batik Component will not recognize fe SVG elem| |17921|New|Nor|2003-03-12|Kerning is broken for standard fonts | |18292|New|Nor|2003-03-24|24 bit PNG not displayed correctly| |18801|New|Nor|2003-04-08|visibility property is not implemented | |19228|New|Blk|2003-04-22|[PATCH] Child LayoutContext is null in certain cir| |19341|Ver|Nor|2003-04-26|leader doesn't work since 0.20.5.rc2 | |19695|New|Enh|2003-05-06|[PATCH] Allow fox:destination as child of fox:outl| |19717|New|Enh|2003-05-07|Lets add support for JimiClassesPro.zip to build.x| |19769|Ass|Enh|2003-05-08|Indefinite page size is not implemented | |20280|Ass|Enh|2003-05-27|text-align and text-align-last only partially impl| |20407|New|Enh|2003-06-02|[PATCH] Configure image caching using the configur| |20827|New|Enh|2003-06-17|Derive other font styles and weights from normal T| |21265|Opn|Nor|2003-07-02|referencing a custom font (TTF or Adobe Type 1) fo| |21905|New|Nor|2003-07-26|large list-item-label bleeds into following block | |21982|New|Maj|2003-07-30|NullPointer Exception in LazyFont with embedded fo| |22450|New|Maj|2003-08-15|Unterminated iteration in JPEGReader class| |22627|Opn|Nor|2003-08-21|Update mirror/download page HEADER README (was [| |24148|New|Nor|2003-10-27|Kerning upsets text-align=end | |24171|New|Nor|2003-10-28|[PATCH] 1st Attempt at Whole Site PDF | |24378|New|Nor|2003-11-04|Minor problem in sample code for embedding| |24663|New|Nor|2003-11-12|fo:block space-after property needs fixing| |25022|New|Nor|2003-11-26|XSL-FO to PCL : images not included | |25341|New|Nor|2003-12-08|percentage resolution not being recalculated on di| |25411|New|Nor|2003-12-10|[WARNING] Error while constructing image from XML | |25432|Ass|Maj|2003-12-11|Cannot embed the User Defined Characters into the | |26047|New|Nor|2004-01-11|Space-after value remembered and used on second do| |26590|New|Nor|2004-02-02|last character width in winansi font is missed| |26848|New|Nor|2004-02-11|PNG images using JIMI instead JAI | |27107|New|Maj|2004-02-20|TTF Reader fails | |27727|New|Maj|2004-03-17|problem displaying Japanese fonts in PDF. | |27890|New|Min|2004-03-24|fop.sh doesn't set exit status| |29632|New|Maj|2004-06-17|Rendered reads fonts from disk everytime it render| |30006|New|Nor|2004-07-09|eps doesn't show up in recent GhostScript versions| |30214|New|Nor|2004-07-20|PSGraphics2D.drawImage incorrect matrix generated | |31039|New|Nor|2004-09-03|URL in basic-link is scrambled by encryption | |31225|New|Nor|2004-09-14|Need embedded page sequence functionality | |31301|New|Nor|2004-09-19|FOP limitation-Summary of columns value at Table F| |31674|New|Enh|2004-10-12|Allow Print Renderer to select Printer and Tray. | |31796|New|Cri|2004-10-20|Fop: Pdf generation dowsn`t work with j2sdk 1.5 |
Re: Best Interface for reading OpenType Files
Hi Alexander,
Alexander Kiel wrote:
Hi Vincent,
I had a look at SeekableStream and I can imagine how the needs resulted
in the ImageInputStream interface. I haven't decided yet if I should use
ImageInputStream directly. Maybe someone else can throw it's two cents
in here.
Here are my two cents: if you make use of classes in javax.imagio at
only one place in your font library, then there’s no need to worry about
creating a more neutral layer. If OTOH you need to use those classes
everywhere, then it makes sense to use a simplified abstraction layer.
That abstraction layer could be shipped as a separate module and evolve
separately. An implementation could be based on imageIO, Apache Commons
IO (?), your own implementation based on byte arrays for testing
purpose, etc.
Thanks for that. I think, I will write a OpenTypeDataInputStream which
is not a FilterInputStream, but takes a ImageInputStream as constructor
argument like a FilterInputStream would take a InputStream. This
OpenTypeDataInputStream will be the API for all the Streams on top of
it. So I would have only one point which depends on ImageInputStream.
You may want to use a factory a la SAXParserFactory. Although that may
go a bit far.
- is memory consumption that much of a problem anyway? I mean, fonts
are
intrinsically big, complex objects and there’s not much we can do
about that. Many scripts in the world can’t do without advanced
features. Making the parsing of some tables optional doesn’t look to
me like the right way to optimise things. That would unnecessarily
complicate the code.
If you only need the metrics, parsing the glyf or CFF table would be
really unnecessary. So maybe a TableFilter interface would be useful.
Like this:
public class OpenTypeFileInputStream {
private TableFilter tableFilter = TableFilter.NO_FILTERING;
public OpenTypeFileInputStream(OpenTypeDataInputStream in) {}
public void setTableFilter(TableFilter tableFilter) {}
}
public interface TableFilter {
public static final TableFilter NO_FILTERING = new TableFilter() {
public doReadTable(Tag tableTag) { return true; }
}
boolean doReadTable(Tag tableTag);
}
A client which isn't aware of TableFilter would not notice any burden
using the API. And the implementation in OpenTypeFileInputStream isn't
so difficult.
This is an interesting idea. But how would you combine filters?
I’d suggest to keep it aside for the moment, and implement it if we are
actually running into performance issues. After all, if some caching is
done, the font should be parsed only once.
- instead of seekable streams, what about a filter that would re-order
the font stream, caching whatever is necessary before re-sending it to
the consumer object?
I don't want to do this. In the OpenType GPOS and GSUB tables you have
maybe 5 levels of nested structures with headers and offsets. It gets
really complex there.
I see... All right then.
- what about giving the font library a “playground” directory by
inversion of control, that it can use to cache things? And if no
directory is given it would use the memory. Maybe a common interface
could be used for that, targeting either the hard drive or the memory.
Sure. By the way - is there any IoC container used in FOP? I did not see
one so far. How is the bootstrapping done? This could be important for a
central FontSource or such thing.
There’s no such thing as IoC container in FOP. I’m not sure how easy it
would be to introduce one. Although that would probably be A Good Thing.
So do design your font library with IoC in mind.
- does the use of serializable objects make sense? What would be more
efficient: re-parsing font data all the time or re-loading
serializable object representation of them?
You mean the font metrics XML files? I've alwas asking me for what
propose they are there. No, I don't think, we need this. I really don't
want to serialize the Advanced OpenType Features! It took me already a
good amount of code to parse just a bit of it.
What I meant was to use the java.io.Serializable interface. I don’t
indeed think XML representations are any useful, apart maybe for
debugging purpose or to have a more human-readable version of the font
file.
IIC there would be next to nothing to do to cache Serializable objects
on the hard drive and retrieve them?
- what about looking at how fontconfig [1] (a font configuration library
for Linux systems) does things? I know it makes use of a cache to
speed up things. Maybe there are good ideas to borrow from there.
[1] http://www.fontconfig.org/wiki/
I don't see speed a a problem as long as we parse every font only once.
Parsing the OpenType font Old Standard Regular and converting it into
a CustomFont is currently about 100 ms.
Best Regards
Alex
HTH,
Vincent
Re: Checkstyle RedundantThrowsCheck
Hi, Jeremias Maerki wrote: On 27.09.2009 13:27:35 Alexander Kiel wrote: Hi Jeremias, Makes sense. I stumbled over that myself from time to time but it didn't really bother me so much to take action. Okay. Can you please modify the checkstyle XML files to reflect that? Sure, but only after a period of at least 72 hours to allow the other committers to raise an objection. I can’t imagine anybody objecting such a well-argued change proposal... Anyway... +1 from me. snip/ Vincent
Re: Checkstyle RedundantThrowsCheck
Alex, The checkstyle checks are historically grown, and are therefore incomplete. I personally would turn on much more checks for certain style issues I like. IMO every option set helps deciding a certain factor. So more the more checks the better :) (in short: +1 to your changes). Right now we have 3 checkstyle files: 3.5, 4.0, and 5.0, which also means the checks would need to be added in all of them (if possible). Can we remove any of them? I'd volunteer to modify the ant buildfile to support 5.0. I'd also vote for dropping 3.5 support, and potentially dropping checkstyle 4. Max 2009/9/26 Alexander Kiel alexanderk...@gmx.net: Hi, why didn't our code style allow unchecked exceptions or subclasses of thrown exceptions in Javadoc? From checkstyle-5.0.xml: module name=RedundantThrowsCheck property name=allowSubclasses value=false/ property name=allowUnchecked value=false/ property name=severity value=warning/ /module From J. Bloch: Effective Java, Second Edition [1] page 252: Use the Javadoc @thows tag to document each unchecked exception that a method can throw, but do not use the throws keyword to include unchecked exceptions in the method declaration. Every good code I know, documents unchecked exceptions. Take the Java Collections API. Every possible ClassCastException or NullPointerException is documented. Another quote from J. Bloch: A well-documented list of unchecked exceptions that a method can throw effectively describes the preconditions for its successful execution. It is essential that each method's documentation describe its preconditions [...] I think that everyone can agree with the statements J. Bloch made. So I would strongly vote to allow documenting unchecked exceptions. The second point is not allowing subclasses of exceptions in Javadoc. I don't use this very often, but I have just one example in my mind where this makes sense. If you have a look into java.io.DataInputStream#readByte(), there are both IOException and EOFException documented. EOFException is a subclass of IOException. As you know a normal InputStream.read() returns -1 at EOF but readByte() doesn't. So it's worth documenting that readByte() is throwing a EOFException instead. So I would also vote allowing subclasses. Best Regards Alex [1]: http://www.amazon.com/dp/0321356683/ -- e-mail: alexanderk...@gmx.net web: www.alexanderkiel.net
Re: Confused about checkstyle use
Hi Guys, Maybe a bit late, but you may find the following page interesting: http://wiki.apache.org/xmlgraphics-fop/FOPIntelliJSetup Feel free to make any additions or corrections to this document. As to the use of checkstyle: I think the rules were set up long after the project was created. So the code that was already existing didn’t follow all of them. And modifying it accordingly isn’t a straightforward nor enjoyable task... However, new committed code is not supposed to break any rule, neither warnings nor errors. HTH, Vincent Jonathan Levinson wrote: Thanks to your advice (and my finding the checkstyle configurator in Idea) I'm now using checkstyle-5.0.xml from FOP. Thank you very much! However, I notice there are still warnings. BlockStackingLayoutManager.java: 16 items Missing a Javadoc comment. (58:5) 'parentArea' hides a field. (115:47) 'parentArea' hides a field. (145:50) Method length is 185 lines (max allowed is 150) (372:5) Etc., I'm using JetBrains IDEA 8.1.3. Is the rule we ignore warnings and only look for errors? BTW, I got Checkstyle to work in IDEA by changing checkstyle-5.0.xml in FOP in the following way: module name=RegexpHeader property name=headerFile value=c:/perforce/Users/levinson/fop-trunk/checkstyle.header/ Thanks again for your help!, Jonathan S. Levinson Senior Software Developer Object Group InterSystems -Original Message- From: Alexander Kiel [mailto:alexanderk...@gmx.net] Sent: Sunday, September 27, 2009 4:55 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: Confused about checkstyle use Hi Jonathan, did you use the checkstyle-5.0.xml from FOP or the default SUN profile? I'm currently not able to start IDEA, but two days ago as I downloaded the plugin, I noticed that the SUn profile was active and I had to define the FOP profile. And if you define the FOP profile, you will properly notice that the header thing did not work. Its a path inclusion problem of the header.* file. I did not have a solution for it, I just commended it out for now. Best Regards Alex Jonathan Levinson wrote: I've installed the Checkstyle plugin for IDEA and the current code when scanned by the plugin shows lots of Checkstyle errors. Here are some errors scanning BlockStackingLayoutManager.java: Missing package-info.java file (0:0) Line is longer than 80 characters. (18:0) First sentence should end with a period (53:0) Variable 'bpUnit' must be private and have accessor methods. (61:19) What does it mean to have clean code according to Checkstyle? Is my plugin misconfigured? Is it by default at too strict a setting? Best Regards, Jonathan S. Levinson Senior Software Developer Object Group InterSystems
Re: omit first table header/last footer
Hi Carlos, Carlos Villegas wrote: Hi, I searched the mailing lists and it seems that although some people had worked at several times at trying to implement retrieve-table-marker, it's not yet done. Is somebody working on this? What's the status? It’s not being worked on at the moment. This is still a missing feature. In many use cases omitting the first table header and the last table footer will do the trick. How easy is this to implement? What will be the steps to add such an extension to FOP? I just started looking at the code so I'm exploring whether this is viable solution. That might work. You would need to change the o.a.f.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements method. There is a “if (getTableLM().getTable().omitHeaderAtBreak())” test that you could augment with a “ !(omitFirstHeader)” clause. Likewise for the footer. The easiest is to directly modify that class and re-build FOP. A bit less easy would be to add a variable in the configuration file, so that you can enable it only for certain FO files. Even less easy would be to add an extension property to fo:table so that you can enable it only for some tables of an FO document. Please ask if you need more details. All that said, such a change would be very hacky and, unless there is overwhelming demand from the user community, I would oppose to integrate it in the code base. This is a patch that you would have to maintain on your side. Better would be of course to actually implement retrieve-table-marker. Although this would be more involving than implementing this little trick... HTH, Vincent
Re: Questionable whether font-shorthand grammar LL(1)
Hi Jonathan, Interesting stuff! Jonathan Levinson wrote: Hi Vincent, snip/ Because font-variant font-style and font-weight can occur in any order, I could not (currently) come up with a grammar in which the directing sets were disjoint for each non-terminal. So I was unable to come up with an LL(1) grammar. For instance, here are two productions of my attempt at a grammar: style-variant-weight - variant-weight style-variant-weight - variant-style In each case, the first set of style-variant-weight shares a common element in two different productions, the literal values for variant. One needs to look ahead one more token to see if one has a variant-weight or a variant-style. (I’ll call “modifier” any of the three style, variant, weight properties.) Taking the ‘normal’ case apart, and since ‘inherit’ is not allowed in the shorthand, I think the values for all modifiers are distinct: ‘italic’, ‘oblique’, ‘backslant’ for font-style, ‘small-caps’ for font-variant, and the various weight values for font-weight. Since all modifiers are set to their initial values prior to the shorthand parsing, which is ‘normal’ for all three of them, I think we can simply ignore any ‘normal’ value found in the string. That is, accept it as a legal terminal but not do anything. So I don’t think there is any ambiguity any more. What remains to be done is to check that the same modifier is not specified more than once (that includes checking that ‘normal’ is not specified more than 3 times). And it’s probably easier to check that at the semantic level instead of crafting special grammar rules. snip/ The books and web articles I read only discussed using recursive descent when the grammar is LL(1). I have the feeling that despite the ambiguities in the grammar it is almost LL(k) because font-variant and font-style and font-weight almost have disjoint values. It is at least LL(3) and I suspect it is LL(6). The font-size property has the good idea of not allowing ‘normal’ as a value. The ‘normal’ case for modifiers can be ignored as explained above. So I think the grammar still is LL(1) snip/ I'm not as convinced as you are that recursive descent parsing or a formal bottom-up-parser will make the code simpler rather than more complex because of the complexities of a formal grammar. Of course, however complex the grammar, a table-generating tool - like ANTLR - will generate code, however complex, which will faithfully reflect the inputted grammar. However, none of the other properties in FOP use a table-generating tool like ANTLR - and I'm not sure what the consequences would be to FOP of introducing such a tool. Given the complexities of the grammar, I'm sure that a recursive descent parser will be quite complex, and if we are going to use a grammar driven approach we would be better off with a tool that generates parsers from grammars rather than the recursive descent approach. Also an advantage of parser generators is that one doesn't have to rewrite so much code to correct a mistake in one's grammar, if one makes a mistake, or if the grammar changes. Recursive descent parsing can pose its own maintenance nightmares. Using a grammar tool like ANTLR is probably overkill to parse just a shorthand property. Moreover the grammar is not likely to change, so that reduces its usefulness even more. That said, most properties can accept expressions, where such a tool might actually be interesting. I don’t know how far FOP goes to supporting expressions in other properties. The current approach in FOP for font-shorthand is obscurely written but strikes me as basically sound. 1) One parses from right-to-left using the fact that spaces divide tokens The problem is that font families can be specified with strings containing whitespace, that must be handled in a specific manner and not as a terminal delimitation. Otherwise parsing from right to left would indeed probably be relatively easy. 2) One lets property makers determine whether they apply to a token. Each property maker is a little parser of the token one feeds it. Because the property makers determine whether they apply to a token, one can handle the fact that variant, weight and style can occur in any order by feeding the current token to each of the property makers for font-variant, font-weight, and font-style in turn. Whatever they accept is ipso-facto a font-variant or a font-weight or font-style. Just want to let you know I take the problem seriously, and I'm not trying to duck the responsibility of coming up with an adequate solution. I'm not sure what I did fits into a job priority which is why I spent many hours this weekend on this research. Thanks for looking into this issue. I hope my comments above can help. As an alternative: the fact that the shorthand property can be parsed using a regular expression shows that its grammar is a regular language [1], thus can also be
DO NOT REPLY [Bug 46883] AFP/GOCA: Performance Hot Spot in AbstractGraphicsDrawingOrderContainer.getDataLength()
https://issues.apache.org/bugzilla/show_bug.cgi?id=46883 Jeremias Maerki jerem...@apache.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from Jeremias Maerki jerem...@apache.org 2009-09-28 07:14:41 PDT --- I had to revert revision 807010 because it caused a regression. Even very simple SVGs (for example [1]) converted to GOCA caused faulty documents. Due to time pressure, I'm afraid I cannot currently invest more time than I already have on fixing this, so I'm just reverting the change and reopening the bug. Sorry. http://svn.apache.org/viewvc?rev=819542view=rev [1] http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/test/resources/images/img-w-size.svg -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: omit first table header/last footer
Thanks for the pointers. I agree that implementing retrieve-table-marker is not only a more generic solution but also what the spec requires. However, I'm short on time and this seems easier so I'll give it a try first. Regards, Carlos Vincent Hennebert wrote: Hi Carlos, Carlos Villegas wrote: Hi, I searched the mailing lists and it seems that although some people had worked at several times at trying to implement retrieve-table-marker, it's not yet done. Is somebody working on this? What's the status? It’s not being worked on at the moment. This is still a missing feature. In many use cases omitting the first table header and the last table footer will do the trick. How easy is this to implement? What will be the steps to add such an extension to FOP? I just started looking at the code so I'm exploring whether this is viable solution. That might work. You would need to change the o.a.f.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements method. There is a “if (getTableLM().getTable().omitHeaderAtBreak())” test that you could augment with a “ !(omitFirstHeader)” clause. Likewise for the footer. The easiest is to directly modify that class and re-build FOP. A bit less easy would be to add a variable in the configuration file, so that you can enable it only for certain FO files. Even less easy would be to add an extension property to fo:table so that you can enable it only for some tables of an FO document. Please ask if you need more details. All that said, such a change would be very hacky and, unless there is overwhelming demand from the user community, I would oppose to integrate it in the code base. This is a patch that you would have to maintain on your side. Better would be of course to actually implement retrieve-table-marker. Although this would be more involving than implementing this little trick... HTH, Vincent
Re: When must the structure tree be output in the PDF file?
Hi Jeremias, Jeremias Maerki wrote: snip/ IFParser is also still missing the parse code for the structure tree. I guess I would defer the call to startPageSequence in the IFParser, then parse the reduced FO tree using a ContentHandler delegate, set that on the user agent and then call startPageSequence when the first page tag is encountered. That’s what I ended up doing. Thanks for your input, Vincent On 24.09.2009 13:07:11 Vincent Hennebert wrote: Jeremias Maerki wrote: Not just like that (if at all). The content items being produced inside the page-sequence have to be linked into the structure tree. There are links (MCIDs) back and forth between the structure tree and the content streams. You have to have the structure tree available while you create the page contents to build up the links. You could probably move the generation to endPageSequence but you'd end up duplicating some of the data structures for establishing the links in the process which you'd then have to map to the PDF library in the end. Not sure if that's what you want. I don't have this stuff present as much as back when I helped Jost, so I may be missing something. Ok, then there’s the following problem: when creating the PDF document out of an IF XML file, the structure tree is not yet available at the time PDFDocumentHandler.startPageSequence is called. Indeed in the IF the structure tree is stored as a child of the page-sequence element. Any idea of how to handle this, other than putting an ugly boolean at the beginning of PDFDocumentHandler.startPage, “if structure tree not yet built, then build structure tree”? On 23.09.2009 13:44:11 Vincent Hennebert wrote: To those PDF specialists around here: am I right that the structure tree could as well be converted into PDF at the end of a page sequence, as at the beginning? In other words: could the piece of code dealing with the structure tree be moved from PDFDocumentHandler.startPageSequence to PDFDocumentHandler.endPageSequence? Thanks, Vincent Jeremias Maerki Thanks, Vincent Jeremias Maerki
Re: Confused about checkstyle use
Hi Vincent, However, new committed code is not supposed to break any rule, neither warnings nor errors. Really? That means commenting every public method even simple Getters and Setters? Commenting equals(), hashCode() and toString()? I think, this would be only clutter. Best Regards Alex signature.asc Description: This is a digitally signed message part
RE: Confused about checkstyle use
Hi Jonathan,
However, I notice there are still warnings.
BlockStackingLayoutManager.java: 16 items
Missing a Javadoc comment. (58:5)
'parentArea' hides a field. (115:47)
'parentArea' hides a field. (145:50)
Method length is 185 lines (max allowed is 150) (372:5)
Etc.,
At BlockStackingLayoutManager my right side is almost completely
yellow :-) In German, I would say: Monsterklasse. :-)
I'm using JetBrains IDEA 8.1.3.
I too.
BTW, I got Checkstyle to work in IDEA by changing checkstyle-5.0.xml in
FOP in the following way:
module name=RegexpHeader
property name=headerFile
value=c:/perforce/Users/levinson/fop-trunk/checkstyle.header/
Yes, this solution is obvious, but not very suitable as you can't commit
this file with your private path.
Can someone of the older project members point us to some info, why this
${samedir} property did not work in IDEA?
Best Regards
Alex
-Original Message-
From: Alexander Kiel [mailto:alexanderk...@gmx.net]
Sent: Sunday, September 27, 2009 4:55 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Confused about checkstyle use
Hi Jonathan,
did you use the checkstyle-5.0.xml from FOP or the default SUN profile?
I'm currently not able to start IDEA, but two days ago as I downloaded
the plugin, I noticed that the SUn profile was active and I had to
define the FOP profile. And if you define the FOP profile, you will
properly notice that the header thing did not work. Its a path inclusion
problem of the header.* file. I did not have a solution for it, I just
commended it out for now.
Best Regards
Alex
Jonathan Levinson wrote:
I've installed the Checkstyle plugin for IDEA and the current code
when scanned by the plugin shows lots of Checkstyle errors.
Here are some errors scanning BlockStackingLayoutManager.java:
Missing package-info.java file (0:0)
Line is longer than 80 characters. (18:0)
First sentence should end with a period (53:0)
Variable 'bpUnit' must be private and have accessor methods. (61:19)
What does it mean to have clean code according to Checkstyle?
Is my plugin misconfigured? Is it by default at too strict a setting?
Best Regards,
Jonathan S. Levinson
Senior Software Developer
Object Group
InterSystems
signature.asc
Description: This is a digitally signed message part
Re: Best Interface for reading OpenType Files
Hi Vincent,
Here are my two cents: if you make use of classes in javax.imagio at
only one place in your font library, then there’s no need to worry about
creating a more neutral layer. If OTOH you need to use those classes
everywhere, then it makes sense to use a simplified abstraction layer.
That abstraction layer could be shipped as a separate module and evolve
separately. An implementation could be based on imageIO, Apache Commons
IO (?), your own implementation based on byte arrays for testing
purpose, etc.
Thanks for that. I think, I will write a OpenTypeDataInputStream which
is not a FilterInputStream, but takes a ImageInputStream as constructor
argument like a FilterInputStream would take a InputStream. This
OpenTypeDataInputStream will be the API for all the Streams on top of
it. So I would have only one point which depends on ImageInputStream.
You may want to use a factory a la SAXParserFactory. Although that may
go a bit far.
Hmmm. I don't see the benefit of such a factory here. The
OpenTypeDataInputStream would look like this:
public class OpenTypeDataInputStream {
private final ImageInputStream in;
public OpenTypeDataInputStream(ImageInputStream in) {
this.in = in;
}
public final int readUnsignedShort() throws IOException {
[...]
}
public final Tag readTag() throws IOException {
[...]
}
}
This is the common FilterInputStream pattern. OpenTypeDataInputStream
only depends on ImageInputStream which is an interface.
OpenTypeDataInputStream is really simple and straitforward, so that I
can't imagine different implementations. Except implementations on top
of other things as ImageInputStream. But than we are at the question, if
we want ImageInputStream the common interface for different
implementations (on top of files, streams, byte arrays) or if we want
OpenTypeDataInputStream to do that. I think that ImageInputStream is the
right place, because it abstracts from getting bytes and be able to
seek. OpenTypeDataInputStream on the other hand implements the semantics
of the common OpenType data types, which are well defined in the
specification.
If you only need the metrics, parsing the glyf or CFF table would be
really unnecessary. So maybe a TableFilter interface would be useful.
Like this:
public class OpenTypeFileInputStream {
private TableFilter tableFilter = TableFilter.NO_FILTERING;
public OpenTypeFileInputStream(OpenTypeDataInputStream in) {}
public void setTableFilter(TableFilter tableFilter) {}
}
public interface TableFilter {
public static final TableFilter NO_FILTERING = new TableFilter() {
public doReadTable(Tag tableTag) { return true; }
}
boolean doReadTable(Tag tableTag);
}
A client which isn't aware of TableFilter would not notice any burden
using the API. And the implementation in OpenTypeFileInputStream isn't
so difficult.
This is an interesting idea. But how would you combine filters?
I’d suggest to keep it aside for the moment, and implement it if we are
actually running into performance issues. After all, if some caching is
done, the font should be parsed only once.
The idea of TableFilter is borrowed from java.io.FileFilter. If you look
at org.apache.commons.io.filefilter.AndFileFilter and so on, you get an
Idea how one could combine such filters.
Sure we had to implement some sort of dependencies between tables, if we
want to save the user from surprises.
There’s no such thing as IoC container in FOP. I’m not sure how easy it
would be to introduce one. Although that would probably be A Good Thing.
So do design your font library with IoC in mind.
Yes, I will. We can use IoC even without a container. And if we want to
choose one, I have plenty experience with spring. So if I should vote,
it would properly vote for spring.
- does the use of serializable objects make sense? What would be more
efficient: re-parsing font data all the time or re-loading
serializable object representation of them?
You mean the font metrics XML files? I've alwas asking me for what
propose they are there. No, I don't think, we need this. I really don't
want to serialize the Advanced OpenType Features! It took me already a
good amount of code to parse just a bit of it.
What I meant was to use the java.io.Serializable interface. I don’t
indeed think XML representations are any useful, apart maybe for
debugging purpose or to have a more human-readable version of the font
file.
IIC there would be next to nothing to do to cache Serializable objects
on the hard drive and retrieve them?
Hmmm. Ok. But if we want to use Serializable for that, your classes have
to be very stable. Versioning the Serializable stuff is a real burden in
my opinion. So we will need a cache which detects version changes and
invalidate the objects if so. Do you know such a lib?
Best Regards
Alex
Re: Confused about checkstyle use
Alex,
2009/9/28 Alexander Kiel alexanderk...@gmx.net:
Hi Vincent,
However, new committed code is not supposed to break any rule, neither
warnings nor errors.
Really? That means commenting every public method even simple Getters
and Setters?
Yes. Simple Getter and Setters are the only place where you can
publicly document private variables. (in most cases, comment in the
getter and link from the setter)
Commenting equals(), hashCode() and toString()? I think,
this would be only clutter.
/** {...@inheritdoc} */
would do the trick on those, UNLESS they implement something which is
unexpected (such as the equals methods I recently renamed which did
not implement equals) or special (a toString which creates a
guaranteed parsable result for example)
Best Regards
Alex
hth
Max
