Re: PDFName.getName() returns escaped name?!
Am 29.03.2012 01:24, schrieb Craig Ringer: I'd also like to have getEncodedName() return a byte[] not a String, since an encoded PDF name isn't actually text data. Sounds like a reasonable idea. BTW, is there any reason Fop's PDF library uses java.lang.String when working with sequences of PDF data bytes? I'd chalk this up to historical reasons, as usual. Fell free to provide a patch which cleans this up. J.Pietschmann
Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/org/apache/fop/render/ src/java/
Am 25.01.2012 15:59, schrieb mehdi houshmand: This would mean deprecating o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not mistaken) this is legacy code to bind a MIME type to IF output. AFAIR it was meant as a hook for users providing their own renderer, overriding built-in renderers for the same MIME type. E.g. some hacked-up AFP-renderer or something. I wish Jeremias would come forward and provide some more background. J.Pietschmann
Re: Static main methods
Am 27.01.2012 16:35, schrieb mehdi houshmand: There seem to be an awful lot of static main methods around the fonts and hyphenation packages, I was wondering if anyone had any objections to moving all these methods into classes under a single package i.e. AFAIR all of these are there to facilitate development and testing, the font metrics and the hyphenation class generator being the only exceptions. They are not meant for the average user. Most if not all could probably be deleted, or a least moved into the test tree. I'm not sure what to do with the metrics generator, as the metrics file is deprecated anyway. The hyphenation class generator is already a class for itself (which ist overly complicated and could probably share more code with the ant task). Another possibility would be to get rid of explicitely building serialized hyphenation classes and use a caching mechanism for processed hyphenation patterns, somewhat similar to fonts. (FOURIResolver, FontResolver, HyphenationTreeResolver, DataURIResolver, DTDEntityResolver) which I think we can all agree is a little excessive. Unfortunately, there are at least two different APIs involved, and there are still reasons users should be able to set different resolvers for different purposes. Using an underlying unified API makes sense, however I remember unifying DTDEntityResolver and the other Resolvers run into difficulties (maybe related to XML catalogs). J.Pietschmann
Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/org/apache/fop/render/ src/java/
Hi Mehdi! Am 23.01.2012 17:15, schrieb me...@apache.org: This breaks the public API but for good reasons: Good reasons or not, there are a few guidelines when it comes to changing public interfaces: - There has to be a discussion of the change. Alternatively, open a bugzilla ticket and provide reasons and the proposed solution/patch for inspection (yes, even committers should do that) - It's good practice to call a vote after the pros and cons of the change have been laid out. - It's also good practice to deprecate functionality which is going to be removed, in order to maintain compatibility for at least one release cycle and give users time to adapt. Please revert the commit. J.Pietschmann
Re: not letting me put xsl:tempate inside fo:root
On 04.05.2011 20:15, Brian wrote: Are we not allowed to put xsl:template inside fo:root? No. According to the XSLT spec, xsl:template must be an immediate child of xsl:stylesheet, see http://www.w3.org/TR/2007/REC-xslt20-20070123/#element-stylesheet and other parts of the spec. Outside fo:root it works fine, but this doesn't help me in this particular scenerio. The xsl:template element is a declaration, so your statement makes me think you are seriously confused about how XSLT works. The best way to clean this up is usually to send a problem description to the XSL list, where the gurus tend to hang out. Guidelines and subscription advice here: http://www.mulberrytech.com/xsl/xsl-list/ J.Pietschmann
Re: FindBugs exclusion policy proposal
On 27.02.2011 02:46, Glenn Adams wrote: My expectation (not hope) was that once we eliminated the pre-existing findbugs, that new commits would not add new issues. Otherwise, it is a pointless exercise. My conclusion is that since findbugs does indeed identify some real and potential bugs, that it is worth using and that a zero findbugs policy should apply. Well, while findbugs indeed finds real issues and improves maintainability of the code, I don't think I'd have enough time to commit myself to examine each and every findbugs complaint carefully, rather then just plaster it over with an exception, and I think it's the same with Jeremias. This doesn't mean we throw it out. As of now, anybody is free to run the findbugs target and fix issues which come up. Installing a zero findbugs issues policy is a rather drastic step, which will, believe it or not, raise barriers for contributions, divert resources and possibly have some other undesirable effects, like name calling on public lists. Unless we all are convinced we have the resources to lead by example and that the positive effects of a zero findbugs issues policy outweigh any possible drawbacks, running findbugs should be voluntary. However, saying all of the above, the largest barrier I see to fixing bugs in FOP and improving its quality is the reticence of the clique of FOP committers to accept new committers. Uh oh. As a PMC member I'm certainly guilty of not following contributions closely enough. Nevertheless, rest assured this has nothing to do with some elitist attitude but rather with a I hope someone else will deal with this kind of aspects stance, aka a sort of laziness. I do not expect you to show sympathy for this now, but in case you get the possibility to recruit someone else, and realize the procedures necessary for this, you'll understand it better (I might get some fun out of reminding you of this message then). HTH J.Pietschmann
Re: TODO tag [was: Re: svn commit: r990148 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/ fo/ fo/flow/ fo/flow/table/ fo/pagination/ fo/properties/ hyphenation/ layoutmgr/ layoutmgr/inline
On 02.09.2010 12:14, Glenn Adams wrote: also the doclet options to permit use of @todo without warnings. I could try to experiment some to see if that is feasible, then we could return to the former usage of @todo. Javadoc 1.5 or later can be passed a command line option defining additional tokens to accept: http://download.oracle.com/javase/1.5.0/docs/tooldocs/windows/javadoc.html#tag I vaguely remember to have had it working in my local build.xml some times ago. J.Pietschmann
Re: findbugs results
On 18.08.2010 15:01, Simon Pepping wrote: FOP committers, interested in having our code analysed there? Certainly. BTW Sonar is Open Source, installing it for local use is easy. J.Pietschmann
Re: Font Glyph?
On 15.07.2010 22:44, Eric Douglas wrote: Then I pass a text value of #x2611; in my XML. When the transformer uses FOP to translate the XML into output, this prints a square. Have a look at http://www.unicode.org/charts/charindex.html U2611 is BALLOT BOX WITH CHECK, i.e. not a square (U2610 should be a square, are you sure about the entity?) If FOP couldn't find the glyph, it would have printed a # instead. You could use one of the font editors to check whether your font actually has a glyph for the U2611 character (try http://fontforge.sourceforge.net/) I tried replacing my fop.jar with one that I compiled from the Trunk, and instead of printing the square it printed an error message to the Java Console that the font doesn't contain the specified glyph. That's mildly odd, I'd guess your method for telling FOP about your font doesn't work as in Trunk. J.Pietschmann
Re: SEVERE: Couldn't find hyphenation pattern en_US
On 23.06.2010 18:08, Tom Browder wrote: I'm trying to understand how the distributable packages on the fop download site are assembled, by hand or by script? If by script, where is it? It's the build.xml file. You'll need ant (http://ant.apache.org) to run it, the target dist will generate tgz and zip archives for both a binary and a source package. It will not generate a package which can be used by the Ubuntu package system. They wont contain the jar with the hyphenation classes either. J.Pietschmann
Re: SEVERE: Couldn't find hyphenation pattern en_US
On 22.06.2010 19:02, Tom Browder wrote: I have tried to explicitly point to the fop-hyph.jar file with the FOP_HYPHENATION_PATH environment variable but that doesn't seem to work. The fop-hyph.jar must be in the classpath, putting it into the fop/lib directory should be sufficient if FOP is run using one of the scripts as they pick up any jar there. I'm not sure whether the fop-hyph.jar from the OFFO project contains an en_US hyphenation class, maybe there is only an en_UK class there. Check using jar -tvf lib/fop-hyph.jar J.Pietschmann
Re: DO NOT REPLY [Bug 48108] Special Characters are not rendering
On 03.11.2009 08:45, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=48108 [Snip] Hi Devs, I want to get an opinion: Should we start to emit error messages if there is no glyph for a character in the current font set? Of course, the user shouldn't be drowned in essentially the same message over and over again, perhaps by deferring the message to the end of processing and trying to compressing multiple missing characters to ranges or something like mulitple characters from unicode block NNN didn't have a glyph in font ... J.Pietschmann
Re: TTF Fonts in FOP v0_20_5
On 04.09.2009 10:55, JPee wrote: I'm working with FOP embedded in a CMS and using verdana (referenced as verdanattf.tff) and georgia (referenced as georgia.ttf), also with bold and italic fonts of it. When I generate a PDF and copy a word, everything i get is and not the correct letters, searching in the document is because of that problem also not possible. FOP 0.20.5 doesn't generate CID maps which are necessary to copy or search text associated with user defined fonts. Is there a way how it works correctly with true type fonts? The PDF generated by FOP 0.20.5 allows copying and searching only for texts rendered with built-in PDF fonts. Either you'll have to use Times or Courier, or upgrade to FOP 0.95. J.Pietschmann
Re: FOP Version v0_20_5 linkproblem
On 04.09.2009 10:49, JPee wrote: If I use a basic link and the external-destination is linked to a pdf, all / (slashes) turn into \ (backslashes). As a wild guess: if you generate the PDF with the backslashes on Windows, try on a UNIX/LINUX system and check whether the problem goes away. Other than that, you'll either have to upgrade FOP to a more recent version or hack the URL resolver from 0.20.5 yourself. J.Pietschmann
Re: [VOTE] Merge branch for new Intermediate Format into Trunk
On 16.02.2009 17:11, Jeremias Maerki wrote: As mentioned earlier, I would like to start a vote for merging the Intermediate Format branch [1] (revision 744946) into Trunk. +1 from me too, looks good. J.Pietschmann
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
On 27.11.2008 16:33, Max Berger wrote: The recent amount of discussion shows that your branch should be integrated into trunk as soon as possible, since it touches other areas as well, and these issues need to be resolved before 1.0beta. I got the same impression, but I don't know anything about the code itself. So +0.5 from me too. J.Pietschmann
Re: Remove FAQ Entries Related to 0.20.5
On 18.11.2008 12:14, Vincent Hennebert wrote: Guys, What do you think of removing entries in the FAQ section that are specific to 0.20.5 and earlier versions? This would make it shorter, so less likely to scare people away, and in the same time easier for them to find the answer to their question. Plus it would stress the fact that we no longer support 0.20.5. +1 from me. Reminds me that FAQ work is still on my agenda. J.Pietschmann
Re: Fwd: FOP with Hebrew/Arabic
On 31.10.2008 18:53, Andreas Delmelle wrote: a) inherent directionality (Unicode BIDI embedding) is not implemented The good news: We can now use the Java 1.4 BIDI stuff. Maybe something from Oleg Tkachenko's patch can be resurrected. J.Pietschmann
Re: Website: Areas of Expertise
Luis Ferro wrote: I'm no hacker of svn, but it should be possible to generate the table based on the commits only... and a date threshold for the last commit by each contributor. Just an idea to automate it... http://www.ohloh.net/projects/fop/contributors All the good ideas are already taken! J.Pietschmann
Re: svn commit: r677648 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java
Andreas Delmelle wrote: I understand... I still think it's a nice showcase for character-by-character font-selection added by Max, so I'm wondering, if the AFPRenderer is the only exception, we should be looking at a way to fall back with a warning, rather than disabling the feature for all other output formats as well (?) I think we could ask the renderer about available fonts. How should the API look like? J.Pietschmann
Re: svn commit: r665699 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/flow/table/ layoutmgr/ layoutmgr/inline/ layoutmgr/list/ layoutmgr/table/
Jeremias Maerki wrote: Frankly, I'm less than thrilled. I appreciate the good will behind this but I'd have appreciated some advance warning, too. My concern is that: -ListElement last = (ListElement)contentList.getLast(); is much easier to read and write than: +ListElement last = (ListElement) contentList +.get(contentList.size() - 1); It may even be faster, unless LinkedList specifically optimizes get(contentList.size() - 1). Well, I think a List should be used if only List methods are needed, and a specialized subclass should be used if methods of the subclass have to be used. Years ago, while I replaces Java 1.1 collection classes with 1.2 I learned that replacing unnecessary use of specialized subclasses with more generic classes without a tool is rather difficult. I vaguely remember of a commercial tool which can report unnecessary use of specialized subclasses (in general), as well as unnecessary broad access control (i.e. public when protected is sufficient). Does anybody of an open source tool which does this too? J.Pietschmann
Re: Switching to Java 1.5
Max Berger wrote: I have to disagreee. AAMOF, java 1.5 is ONLY supported on a select number of plattforms, mainly the ones Sun provides the JDK for (or is licensed). Well, gcj claims 1.5 compatibility and can be compiled on almost anything. My personal experience on a Debian AMD64 platform is that they still have a rather long list of problems to resolve, in particular I wasn't even able to build FOP trunk. J.Pietschmann
Re: Can not check out Trunk with SVN
bonekrusher wrote: Speak to your network administrators about fixing up their proxy configuration. - this will never happen. Alternatively, try HTTPS, which should go through the proxy: svn co https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/ J.Pietschmann
Re: svn commit: r653202 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/TextLayoutManager.java
[EMAIL PROTECTED] wrote:
kern = font.getKernValue(previous, c) *
font.getFontSize() / 1000;
-}
+}
if (kern != 0) {
Uh, oh. Something went wrong with autoindentation?
J.Pietschmann
Re: Processing Feedback: How to handle things like Batik's user agent?
Jeremias Maerki wrote: Something like that. The only problem with creating this is a static context: I don't know for which processing run I create the user agent. I didn't have alook at the actual code, but I thought the Batik User Agent can be created once the first SVG is processed. (Same for user agents for other extensions) The current FOP user agent might be passed to the foreign-extension element which ought to be responsible to create the extension specific user agent, and might provide a context. The FOP user agent might have to get methods to store and retrieve extension specific user agents for use for rendering other extension elements of the same kind. J.Pietschmann
Re: Processing Feedback: How to handle things like Batik's user agent?
Jeremias Maerki wrote: 2. I could also build a hook of some sort so the caller/user can control the creation of the SVG user agent [snip] Option 1 sounds more straight-forward but somehow 2 feels better even though it's probably more complex and takes a little experimenting to do right. It also means that the user has more work and needs to learn about more than just FOP's event system. I also like the second option more than the first. Maybe the two can be combined: let FOP provide an user agent which funnels Batik's messages into FOP's event system and which is used by default, but allow for an override. I'd think of a service mechanism, so that applications which want to consume Batik messages directly just have to drop their jars before the FOP jar into the classpath, and use lazy creation of the user agent. J.Pietschmann
Re: Update: XML JARs
[EMAIL PROTECTED] wrote: FWIW: running FOP out-of-the-box to me is also a much more important concern than removing those JARs, so I'm in favor of keeping the status quo for now. Seconded. J.Pietschmann
Re: Q: What should happen when an image is not found?
Vincent Hennebert wrote: Adrian made the suggestion some time ago of using the fo:declarations element to override configuration on a per-document basis: [snip] It’s not as fine-grained as a PI (no means to say “from now on, do this”), but I share Jeremias’ feeling about PIs. From my experience, a mechanism saying “from now on, do this” is likely to confuse a non-trivial amount of users. I think there should be the following hierarchy (which is already complex enough) - config file - overridden by command line arguments - overridden on a per document basis by extension elements in the fo:declarations section - overridden on a per element basis by extension attributes on the element - overridden by specific force command line arguments (force all warnings/problems to be fatal may be the only one of this kind) J.PIetschmann
Re: Remove deprecated methods in outer API for 0.95?
Jeremias Maerki wrote: For some time now we have a number of methods in our outer API that are deprecated. I think we should remove them now. Anyone against my doing that as part of the preparations for the release? They've been deprecated for long enough time now. So +1. J.Pietschmann
Re: What to do with the XML JARs?
Jeremias Maerki wrote: That means that as long as we have Batik as a mandatory dependency [1] on our core we also have a dependency on DOM Level 3 and Xalan-J which means we cannot remove any of the 4 JARs, except xerces.jar probably which doesn't really have a big effect in itself. Hehe. We're back to my solution 2 (or the status quo). And it would mean we can simply use javax.xml.xpath as we like. Whoa! Pull that tail end hanging out of the foliage and you get an elephant! J.Pietschmann
Re: What to do with the XML JARs?
Jeremias Maerki wrote: - Our test code has a (useful) dependency on Xalan's XPath API. Java 1.4 provides an old JAXP version without XPath support (javax.xml.xpath, available with Java 1.5). So we've got a problem here for the time being. Although it is valuable that users can run the test cases, I don't see it as a production activity, and we could just require them to use Java 1.5 in this case. 2. Move the 4 JARs to a lib/endorsed directory and adjust our scripts to insert them into the bootclasspath ... - User might wonder why the JARs are suddenly in a different place. Even worse, this might affect unrelated code for no obvious (to the user) reason. I guess it's clear that only solution 2 makes sense if we want to change something. I'm not really fond of this idea. I think the simplest solution is to remove the jars, and require developers and curious users who want to run tests to use a 1.5 or newer environment for this. An ant trap testing for the critical JAXP classes can prevent running the tests in older environments. J.Pietschmann
Java 1.4 compatibility
Hi devs, I just started to import a FOP project into my brand new shiny Eclipse installation on Debian Etch, and quickly found out that I unexpectedly signed up for checking FOP's 1.4 compatibility. There are numerous assert statements in files related to table layout. Should I just comment them out? J.Pietschmann
Re: Closing bugs in bugzilla.
Vincent Hennebert wrote: Pascal Sancho wrote: Sorry for the noise, I end with the bug #20950. I hope this will save some time to FOP team. Great and important work, no need for excuses! Indeed! Our bug database has been needing a serious cleanup for a long time anyway. So thanks for taking care of this! Doubled! Just asking: did you make sure that the bugs were actually corrected by making a proper test? For example, bugs said to be solved on version 0.20.5 might still exist in the Trunk, since the fork was made from version 0.20.2. It is plausible that most if not all of the layout and border/margin related bugs disappeared during the rewrite. J.Pietschmann
Re: More about the effects of the PropertyCache
Andreas L Delmelle wrote: The CommonBorderPaddingBackground is still a memory eater, but I'll have to take a look at LengthRangeProperty and CondLengthProperty first for that. The trick is probably to split it BPBs in a set of specified data which can be cached and the resolved data. Another idea I pursued (without success) in 0.20: some properties can only have a very limited set of values, in particular text-decoration, keeps, and a few others, which can probably implemented as singletons instead of using a cache. For properties like hyphenation-ladder-count which are likely to have only a few values from a potentially unlimited domain, a mix of pre-fabricated singletons for the most likely used values and a list in case another value is specified, without pruning during rendering, might provide the best balance between memory efficacy and performance. J.Pietschmann
Re: IntMap.java
Vincent Hennebert wrote: Shall we launch a poll on fop-user about abandoning support for 1.4 and require 1.5 as a minimum? :-] A poll: maybe. Abandoning 1.3: Not yet. If the usage of those hash maps is only in a few places, we could provide JDK dependent code and tell people that FOP runs faster on JDK 1.5. J.Pietschmann
Re: Remove Useless Comments
Andreas L Delmelle wrote: The javadocs build with only one small warning concerning @todo tags somewheres (which I don't take to be a major issue) The @todo is a custom tag, which are available with Java 1.4. I thought I added a definition for this to the javadoc task in build.xml. In principle we could use @todo tags to generate a todo document for the web site, if we hadn't already a wiki page for this. J.Pietschmann
Re: svn commit: r556112 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/truetype/TTFFile.java util/IntMap.java
Vincent Hennebert wrote: Addition of a general-purpose int-to-int map ... ... This change makes me a bit uneasy. No doubt that this class is clever and efficient and working, but that's something more to maintain. Jakarta Commons Collections has all kind of clever implementation. Don't they have already something similar, and if not, would it make sense to donate this implementation to Collections? J.Pietschmann
Re: Severe : Exception. Cannot Load Font. No font URI's available.
Chris Bowditch wrote: Although changing configuration files in a backwards incompatible way is not likely to be popular with the users! Given that not embedding fonts never really worked (except for fonts specifically installed using the Acrobat font manager), there is not really an incompatibility. J.Pietschmann
Re: Remove Useless Comments
Jeremias Maerki wrote: Yes, inheritDoc would be the right way, as long as we're on Java 1.4.2 and later (feature not available in 1.3, severly buggy in 1.4.0/1.4.1. I would have switched a long time ago if we weren't still on 1.3. I think of JavaDoc as a sort of compile time feature. I don't think there's still a reason to generate the JavaDocs with a JDK version older than 1.5. It's the byte code which should run in an 1.3 environment, not the HTML'd docs. J.Pietschmann
Re: DO NOT REPLY [Bug 42162] - hyphenation inside block in FOP works only for pure alphabetical characters
Andreas L Delmelle wrote: Seems to me the reporter is wrong to expect that sequence of 80+ digits to be hyphenated under any circumstance, and even the comma-case... Easy enough to come up with such oddities, but when would you ever really need that? And more importantly: Is it really hyphenation you would need then? No, it's more of either wrapping, or alternative line breaking (as in the case of long URLs). Hyphenation applies to words, and words contain letters and in some languages also various punctuation characters. Nevertheless, giving the user some higher level possibilities (i.e. other than inserting ZWS) to control wrapping or alternative line breaking for certain long character sequences where UAX#14 gives unacceptable results is something worth thinking about. Reusing the hyphenator for this might help keeping the necessary code short. J.Pietschmann
Re: DO NOT REPLY [Bug 42162] - hyphenation inside block in FOP works only for pure alphabetical characters
a_l.delmelle wrote in a bugzilla entry: Hyphenation is, in fact, only applicable to pure alphabetical characters. Well, no. The pattern based hyphenator can deal with any Unicode characters (apart from digits, whitespace and the dot, which have a special meaning in the pattern definitions). If the word parser would use the character classes from the active pattern file for parsing words, basically anything could be used. This would only need a proper interface for retrieving the character classes. The class canonicalization could even be folded into the parsing process for better performance. J.Pietschmann
Re: Could someone please clarify the spec for alignment-adjust
Max Berger wrote: I am now a little confused about the spec on alignment-adjust. Me too. Well my interpretation is as follows: a positive (percentage or length) value shifts the alignment point down *on the box*, which raises the box. This seems to be consistent. BTW I really like this part of the spec: 'The computed value of the property is this percentage multiplied by ... the font-size if the area was generated by an fo:character, and the line-height otherwise.' This just thwarts treating the fo:character easily. J.Pietschmann
Re: Cannot Build the Apache fop trunk
Shlomi Fish wrote: I cannot build the Apache fop trunk: ... BUILD FAILED /home/shlomi/Download/unpack/graphics/fop/trunk/build.xml:458: Could not create type serHyph due to java.lang.Error: Unresolved compilation problems: The import org.apache.tools cannot be resolved This means the task can't find the ant libraries. That's a bit of an oddity, but not unheard of. It might have something to do how ant resolves the access to its own libraries on Mandriva, every Linux distro seems to come up with its own way to deal with CLASSPATH hell. Your can try various solutions - add the ant jars to your CLASSPATH variable. - move/copy the ant jars to your personal jar repository, create a build-local.properties in your fop/trunk directory, and point the property optional.lib.dir to the jar repository directory - do some similar magic in your .antrc file J.PIetschmann
Re: svn commit: r515217 - in /xmlgraphics/fop/trunk/src/documenta tion/content/xdocs: ./ conf/ dav/ db/ db/revprops/ db/revs/ db/transactio ns/ hooks/ locks/
Jeremias Maerki wrote: I've reverted the two strange revisions. I wonder what happened. Jay's password hash is still in one of the commit mails, now irrevocably spread all over the mail archives of the world. I recommend changing the svn password immediately. J.Pietschmann
Re: Unicode issues
Manuel Mall wrote: Font selection in combination with character substitution. Ligatures and character shaping. Joerg, can you elaborate on this for me please. Fonts may contain glyphs for precomposed Unicode characters, or they may not. If a list of fonts is searched for a glyph of a character, it may be useful to look for - glyphs for the encoded value (which needs the Grapheme Cluster Boundaries stuff from UAX#29) - glyphs for the fully decomposed form (UAX#15 NFD) - glyphs for maximal composition (UAX#15 NFC) As for Ligatures and character shaping: an algorithm for automatically detecting ligature points may use a pattern lookup similar to the pattern based hyphenation. The pattern dictionary should store only either NFD or NFC forms, for the same reason this is advisable for hyphenation. In unicode an 'umlaut' can be represented as 1 or 2 codepoints. What in your opinion should fop do either a codepoint which can be split into two or vice versa? We should choose either NFD or NFC as a canonical representation for hyphenation patters (and, in the future, for similar things), so that hyphenation patterns containing umlauts can be found regardless of the representation of the umlaut in the source file. Currently, we don't care much, which works but may break suddenly. There is obviously a slight space vs. run time tradeoff (NFC ought to be more compact but NFC'ing the source text may be more expensive than NFD'ing). I noticed that PDF prints a # for a word joiner for example. Ouch! That's why I thought that most Cf code points should be dealt with in layout and not be passed to the renderers. It depends on the features of the target format. After all, PDF viewers do kerning and some paragraph typesetting (e.g. line centering) by themselves if properly instructed. The SVG flow text also has some somewhat higher level functionality, which users might prefer to be used. Unfortunately, all this has potential to complicate the FOP layout. J.Pietschmann
Re: Initial soft hyphen support
Andreas L Delmelle wrote: BTW: I took a very quick look, and does anyone know if there is a good reason why Hyphenation.word is a String? The hyphenator interface goes through several wrapping layers, probably due to the usual take working code and wrap it to fit the caller method. This which always seemed to be overly complicated for me. I tried to come up with a comprehensive API for hyphenation (which would also be applicable to spelling and other similar tasks). Unfortunately, there doesn't seem to be any usable standard, all APIs I've seen are very specific or simply horrible. Any simplification is certainly welcome. J.Pietschmann
Re: FOP Memory issues (fwd from fop-users)
Andreas L Delmelle wrote: Based on Jörgs statistics, I'd say that the number of children will most likely never reach the level where using direct index-based access (ArrayList) has its benefits over traversing a tree of references (LinkedList). There may be FOs, specifically fo:flow and fo:table-body, which may have hundreds of children in real documents. If the FOs use access functions for the children, even for adding, each FO can implement a mechanism which suites its purposes best. In particular, page masters and tables can store the regions in typed fields, FOs which don't have children can get rid of the field completely. I'm not sure whether the layout engine places any restrictions on the access to FO children. Is it possible that access is not random? J.Pietschmann
Re: Unicode issues
Manuel Mall wrote: 2. Unicode text boundaries (UAX#29) especially word boundaries. Do we need this? It does not determine the word breaks to which the word spacing property is applied to as this is determined by the treat-as-word-space property. It could be used to determine the words for hyphenation. Probably not worth the trouble. If the pattern based hyphenator is used, words for hyphenation are determined by the character classes declared there. Well, unless someone changes this. 3. Normalisation (UAX#15): Do we need this? Do we need to feed words in some normalised form to the hyphenation. Yes, most definitely. This is a major factor in keeping the pattern based hyphenator both reasonably robust and small for languages which use combined characters, obviously. Other uses for this? Font selection in combination with character substitution. Ligatures and character shaping. There are libraries which already implement UAX#15 properly, e.g. icu4j, but especially icu4j is a rather large blob of a jar. I think Unicode normalization should be handled like PDF encryption: do it if the library is available, otherwise emit a warning and simply skip the step. Maybe BIDI can be done the same way, using the Java 1.4ff libs while keeping some 1.3 compatibility (just without BIDI). 4. Treatment of combining forms: What should / must we do with those character combinations? 5. Formatting control: Word joiners etc.. These need at least be discarded and not given to the renderers. This depends on the renderer. I'm not sure what PDF would do with it, but RTF definitely should get them. While the RTF spec doesn't mention anything about this topic, I'd say RTF visualization is done using advanced renderers, which should take care of character shaping etc. itself. J.Pietschmann
Re: Initial soft hyphen support
Andreas L Delmelle wrote: The SHY character will be presented to the hyphenator simply as a character of the word it appears in. The hyphenator should then be smart enough to recognize this as a special character, and do something like: create a hyphenation point for the SHY, ... Unfortunately, the hyphenator currently isn't as nearly as smart, and it's a major job to push it in this direction. E.g. it means major API changes. J.Pietschmann
Re: CommonBorderPaddingBackground
[EMAIL PROTECTED] wrote: Is there any good reason why CommonBorderPaddingBackground and BorderInfo are Cloneable yet don't implement a clone() method? They were cloned in the more ancient parts of the code based, but this seemed to have been removed already some time ago. Thanks for bringing this inconsistency to light. J.Pietschmann
Re: FOP Memory issues (fwd from fop-users)
Andreas L Delmelle wrote: Which brings us to another important piece of information that would be interesting to know: how big are each of those instances? Quite some time ago I did some statistics on number of children of FOs, using the FOP examples and FO files from bug reports. The breakdown was roughly the following ~50% no children, mostly FOText nodes and FOs like region-body and page-number-citation ~40% one child, mostly blocks and inlines (fo:wrapper) having exactly one FOText node as child 10% 2..10 children 1% more than 10 children, mostly fo:flow, table and table-body and a few blocks, usually wrapping other blocks. Real world documents with more tables and inline formatting might have more multi-child FOs. I haven't checked whether FOText still inherits the children field on trunk. If so, it is certainly a good idea to get rid of this (in the maintenance branch, this had widespread implications). The case of exactly one child might be worth optimizing too. Two possible solutions: A) all FO node implement a FOContainer interface, for example FONode childAt(int) int numberOfChildren() where FOText for example would hardcode return values of null and 0. B) Use a FOChildrenIterator interface with specific implementations for FO nodes which can have none or exactly one child. Furthermore, in the maintenance branch most of the more specific FOs copied children from the generic children list into properly typed fields before starting layout, in many cases the generic children list could have been deleted afterwards if this wouldn't have broken a few generic recursive algorithms like the one adjusting available space due to footnotes. The discussion then had Keiron said he'd even get rid of the generic children list in favour for properly typed fields, thereby giving up some flexibility needed for extensions. This could be implemented with either of the approaches above too (FOContainer interface or FOChildrenIterator interface). J.Pietschmann
Re: Announcements refused
Florent Georges wrote: I can take care of that, if you want. I sent it to the XSL list just a minute ago. Thank you for the offer anyway. J.Pietschmann
Re: text-decoration inheritance
Manuel Mall wrote: I was just looking at some inline handling stuff and came across the inheritance behaviour of the text-decoration property. IIRC one of the problems is merging the various decoration values: fo:wrapper text-decoration=underlinetext1 fo:wrapper text-decoration=overlinetext2 /fo:wrapper /fo:wrapper I'd say text 2 should be both underlined and overlined. I text-decoration were inherited, the decoration of the inner wrapper would already override underlining. In order to turn off underlining, one should use fo:wrapper text-decoration=underlinetext1 fo:wrapper text-decoration=overline no-underlinetext2 /fo:wrapper /fo:wrapper J.Pietschmann
Re: LineBreaking - looking for design idea
Manuel Mall wrote: Probably should do hyphenation at the same time as it iterates over Knuth elements in the LineLM and looks pretty 'ugly' as it modifies the Knuth elements retrospectively. I'm not sure this will pay off. One note in the TeX book about the Knuth paragraph filling algorithm mentions that it called the expensive hyphenation algorithm less often than the naive line filling algorithm (and therefore run faster!). If we do it in the whitesspace loop we would need a means of adding break opportunities to the data structures at this point. One possible solution would be to simply add a ZWSP char at each normal break opportunity I'd go for a Java break mark object, just to avoid any confusion. and a soft hyphen char at every hyphenation point. This sounds *very* expensive, see above. The other idea Andreas suggested, that is to give each Inline LM the last and first character of the their preceeding/following LM when constructing the LM from the FO is also worth a look. Certainly, but it looks somewhat odd to modify semi-high level APIs to cater for a much more low level algorithm. I find access methods more attractive. J.Pietschmann
Re: LineBreaking - looking for design idea
Manuel Mall wrote: However, what about markers. Their content is only known at layout time isn't it? That's an OOPS factor. However, wouldn't this also be a problem for the current whitespace handling? J.Pietschmann
Re: [VOTE] Release of FOP 0.93
Simon Pepping wrote: Herewith I start a vote on this release. The vote will end in 72 hours, that is, on Saturday 30 December 2006 at noon UTC. +1 from me. J.Pietschmann
Re: LineBreaking - looking for design idea
Andreas L Delmelle wrote: Maybe there's a possibility to re-use the existing CharIterators in the fo package? I'd think so. The problem Manuel faces blocked me too from implementing UAX14, because I wanted to avoid another pass using a CharIterator over the text, similar to how whitespace handling was implemented then. Unfortunately I lost track how whitespace normalization and collapsing is handled now. Perhaps setting break marks can be folded into the whitespace handling loop. J.Pietschmann
Re: UAX#14 implementation
Luca Furini wrote: After making the appropriate adjustment to the checks in that testcase ALL testcases are now passing! Wonderful! Me too! text-align=center .conditionality=retain ... Does this happens because that space is just before a .? The dot (FULL STOP) has property IS and prevents break after any character, also even after a space. Interesting, I didn't remember this. Another doubt: why aren't the - signs in text-align and linefeed-treatment possible breaks? They should be, the dash in Unicode 5.0 has the property HY, which allows for a break after. The tables I generated were for 4.1 (or even 4.0) and might have to be updated, I haven't checked. The UAX14 has been updated too, which might have changed the pair table (cahp. 7.3), which is, oddly enough, part of the report instead of a data file. Links: http://www.unicode.org/reports/tr14/ http://www.unicode.org/Public/UNIDATA/LineBreak.txt J.Pietschmann
Re: Could I prepare font metrics file for a font like Webdings (i.e. without Unicode cmap table inside)?
Andrejus Chaliapinas wrote: When I run TTFReader (from 0.92 beta) over Webdings.ttf - I get this output: Parsing font... Reading c:\windows\fonts\webdings.ttf... Number of glyphs in font: 227 2 cmap tables Unicode cmap table not present Unsupported format: Aborting Question - is it possible then to prepare metrics file for this font as well in the same way as for let say Arial? You can try to use the -enc ansi switch and see if it helps. J.Pietschmann
Re: Problem with FOP-0.20.5 -watermark position
Imran Khan wrote: I am using FOP-0.20.5 for xml to pdf conversion. I am facing problem while creating a watermark. For creating a watermark i am using background property of a block . Now problem is that i want the image as the background place centrally. But when i use background-position=center it does not work .I also have tested with background-position-horizontal, background-position-vertical but everything goes in vain. FOP 0.20.5 doesn't support positioning background images well (the image is scaled to fit the whole area, which should look like a centered position in most cases). Also, 0.20.5 is no longer maintained. Please try a more recent release. J.Pietschmann
Re: DO NOT REPLY [Bug 41044] - [PATCH] FOP memory usage patches.
[EMAIL PROTECTED] wrote: [snip] Interesting. This reminds me that quite some time ago I tried to get the text decoration property flyweighted (still in the maintenance code), there are only 8 possible values. Unfortunately, it failed to pay off, apparently there is no advantage in using a pointer compared to three booleans. I'm sure using the flyweight pattern on font properties could reduce the memory footprint, the property bundle is large enough, and documents rarely use more than two dozen or so of combinations (e.g. two fonts, one a single variant (normal) and size, the other three variants (normal, bold, italic), the normal variant in 4 sizes, for a total of 7 different font property bundles). BorderAndPadding might be another case, for example by using a static immutable instance for the empty case. J.Pietschmann
Re: DO NOT REPLY [Bug 41019] - Left-align oddness with long, unbreakable strings following
Simon Pepping wrote: Would this be a good moment to make these features of the breaking algorithm user configurable, like they are in TeX? This allows people to play with the various possibilities without having to modify the code. Probably, if this can be combined with implementing UAX14. J.Pietschmann
Re: Problems with display-align
Bradley Harrington wrote: However, I got that warning even though the image I embedded in the header is smaller than the before-extent (0.5in vs. 0.45in). I am assuming the table is creating the extra space to cause the overflow. FOP puts images into lines, like everything else, and adds additional space (the half-leading) before and after the line. The half-leading is calculated from the line height, which is in turn calculated from the font size in effect at the beginning of the block, unless explicitly overridden. If you want to take the line exactly as much height as the image set the line-height or font-size to 0. (if you put text in such lines, they will look glued together) J.Pietschmann
Re: svn commit: r474218 [1/5] - in /xmlgraphics/fop/branches/Temp_Floats: ./ src/documentation/content/xdocs/trunk/ src/foschema/ src/java-1.4/org/apache/fop/image/ src/java/org/apache/fop/fo/ src/jav
Vincent Hennebert wrote: Comments are welcome, of course. I'm quite impressed. The layout improvements are very exciting. J.Pietschmann
Re: Any thoughts on something like fo:tab support?
Jeremias Maerki wrote: Just be prepared that they may wrinkle their noses. I'd expect them to do exactly this. How should tabs mix with, say, centered text, or BIDI stuff? I'm not convinced it's worth the additional complexity of the spec. J.Pietschmann
Re: Removing deprecated stuff in the High-level API
Jeremias Maerki wrote: If nobody objects I'm going to remove the deprecated elements in the apps package later this week. Umm, couldn't this wait until after the 0.93 release? Well, that's a question, not a veto. If you think it's a good idea, go ahead. J.Pietschmann
Re: XSL-FO 2.0 workshop in Heidelberg next week
Simon Pepping wrote: Block content in inline content is the natural organization of displayed formulas and tables. Demanding that FO generating stylesheets separate them is moving the burden back to them. I am not in favour of that. Ah, I start seeing the point. You might have add images as well. However, I have to agree with Peter about the clarification of the expected behaviour. In particular, is the line before the block adjusted according to text-align or to text-align-last? It could be argued both ways. And I still think that mixing inlines and blocks significantly complicates the FO processor implementation. :-P J.Pietschmann
Re: PATCH for Arabic/Persian Text, and Bidi-override!
Andreas L Delmelle wrote: I was thinking to use an approach analogous to the current refinement white-space handling: one BidiProcessor stored in the FOEventHandler. This may have inindented consequences: some output formats expect the ultimate user client to do BIDI formatting, which means the renderer has to undo some of the mirroring done while constructing the FO tree. J.Pietschmann
Re: XSL-FO 2.0 workshop in Heidelberg next week
Jeremias Maerki wrote: If anyone has any requirements for XSL-FO 2.0 which I should bring up at the workshop in Heidelberg next week, please let me know. Some rough ideas, unpolished, and without even having had a look at both 1.1 and the current 2.0 proposals: - Generalize headers/footers for every block FO, with some control of behaviour: - render at the start resp. end of each (normal) area generated by the FO - render only at page breaks, not at start of first resp. end of last area - render only at start of first resp. end of last area, not at page breaks (complement of previous behaviour) Needed for the dreaded continued next page stuff, which can then be used for lists and other blocks too. - Blocks with multicolumn layout like for body regions (difficult to implement if BPD isn't easily determined from external constraints, needs probably a memory consuming branch bound algorithm for layout). Needed for newspaper-like and journal layouts, for side boxes and such. - Text floating around areas absolutely positioned on a page. This means, among other things, that line areas may be split. In multicolumn layouts, the fixed area may affect more than one column. Needed for some journal layouts, for focus text and images, side boxes and such. - An element to get the total number of pages in a page sequence or for the whole document (instead of formatted page numbers). There are probably some generalizations in there, perhaps the number of pages which are plastered with normal areas from an arbitrary FO. Needed for some legal documents, namely contracts. - more color models - Doing something about the subtotals on this page and number of foo stuff on this page problems, preferably without plugging a complete spreadsheet language into XSLFO. Perhaps a fo:calculate refer=page/fo-id select=xpath expression/ with a possibly slightly restricted XPath expression, which selects from the referenced page. In case of subtotals, the values to be processed should probably be in FO properties (XML attrs) in a canonical lexical representation instead of using the formatted content. This avoids reparsing the formatted, possibly localized content. XSLT can easily generate the additional, redundant data. - Clarify the hyphenation-char stuff. Is it a char or a string? A FO property expression or a shorthand with a special syntax? - Fix the kludge which allows page-number-format=01 to be processed according to common expectations. If done properly, this may fix some other problems like the problem with hyphenation-char above as well. - Recommendations on metadata, references to appropriate standards - Recommendations and/or (non-)contracts on how to handle external ressources if they are used multiple times (e.g. images in static content). Useful to know how the processor may or must not behave if the ressource is dynamically generated on access. More radical thoughts: - Deprecate both list and table elements and replace by a single unified element set for grid layouts. A content flow is a series of blocks, which may contain in a blocks, inlines or a grid of other blocks. - Deprecate mixing inlines and blocks :-P - Invent controls so that blocks can be broken both in IPD and BPD for pagination. This may solve the break wide tables horizontally as well as the parallel flow text problems, unless it is already solved this way in 1.1 - Automatic page master switching in case of IPD overflow. This is the switch to landscape for wide tables/images problem. The difference to explicitely switching page masters is that some other content before/after the wide FO may flow onto the page, thereby avoiding unpleasant white areas on the page before and on the last page of the wide element. Please tell me if you need clarifications on any of the points. J.Pietschmann
Re: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
Simon Pepping wrote: No UML diagrams for FOP available. Would be nice though. As soon as I get some spare time, I'll try http://sourceforge.net/projects/umldot I suspect the diagrams to be somewhat unwieldy. J.Pietschmann
Re: Configuration file problems
Jeremias Maerki wrote: Ok, I consider myself defeated concerning the way we handle the configuration file (See recent threads on fop-users). The Avalon configuration approach is very nice for the developer but obviously bullshit in terms of end-user-friendlyness. Back from vacation, a few quick thoughts: The problem seems to be the unexperienced users who *have* to fiddle with the config file for getting basic features working. Possible solutions: - Reduce the need to fiddle with config settings. Some options - Use conventions instead of explicit values - Autodetection and other rule base approaches This concerns probably mainly the baseStuff* settings - Provide a GUI application for changing commonly changed settings - Get commonly changed settings from a file with an easier format, like Java properties Did I get the problem right? J.Pietschmann
Re: start-indent for line-areas
Vincent Hennebert wrote: A line-area is a block-area I doubt this. Last time I read the spec, I got the impression that lines are not explicit block areas. J.Pietschmann
Re: Implementing OpenType font support, how hard?
Bertrand Delacretaz wrote: Doesn't kerning cause the same problem as smart font features (like automatic ligatures)? It also causes the total width of a group of character to change when the group is split between two lines. AFAICT kerning rarely applies to character pairs which may be subject to line breaks, at least for western alphabets. So I wouldn't worry all that much, except for proper adjustments in case of hyphenation. Arabic, thai and various indian scripts are another matter, but then there are a lot of more basic features for handling these scripts properly missing anyway. J.Pietschmann
Re: Memory leak?
Simon Pepping wrote: IMHO we create a number of circular references in our trees. Circular references in itself aren't a problem for the garbage collector. I've found that code inspection is of limited value for detecting memory leaks. A memory profiler like DrMem (or any more professional tool) is better. J.Pietschmann
Re: Invitation to Cocoon's GetTogether
Jeremias Maerki wrote: Anyone else? No way. Sorry, family and the day job take all the time. J.Pietschmann
Re: Images in FOP 0.92beta
Jeremias Maerki wrote: remember this thread on fop-users? I've just found out what's wrong. Great! There's absolutely nothing wrong with the PDFRenderer or the PDF library concerning reference freeing. It does it so as soon as each image is written to the PDF which always happens immediately. Hm. I'm pretty sure in 0.20.5 a PDF object held a pointer, and the object was using some data while writing a dictionary structure into the PDF stream after all the real content was written. [...] I ended up in the image cache and in the Javadocs for WeakHashMap where I found that little detail that the weak reference is on the key, not the value. Oops, my fault. J.Pietschmann
Re: When to release 1.0?
Jeremias Maerki wrote: We had a vote in March about merging back the API Finalization branch back into Trunk. You voted +1 back then knowing the the branch had the word Finalization in it. Some things just need time to sink in. I don't want style issues block further progress. I brought this topic up only because this seems to be the very last chance for changes. If everybody is ok with as is, then just go forward. J.Pietschmann
Re: When to release 1.0?
Jeremias Maerki wrote: Ok, if we want that 1.0 won't be out before September. Too bad. As already mentioned, changing IPD page masters worked reasonably well in 0.20.5 and I think people will expect this to work in a 1.0 release too. OTOH, if the frequency of questions on the lists are taken into account, support for collapsing table borders, even if only partial, has a much higher priority. I don't see any of the other mentioned features as a show stopper for 1.0. That remark comes pretty late, but yeah, if anyone else think this should be fixed, we should do it SOON. Well, someone should have looked at this before (I made some style related notes during the API discussion). The guide lines are - consistency with the Java RTL identifier guide lines, in particular the rule that common acronyms in identifiers are all upper case - internal consistency - avoiding redundancy We can restrict this to the essential user visible API, i.e. the packages o.a.fop.apps and o.a.fop.cli. My suggestions - Rename o.a.fop.apps to o.a.fop.api. This is a major change breaking everything, and should have been done in the same step when the Driver was replaced by the Fop class. I wont insist on this change. - If the Fop in FopFactory is the acronym for FO processor, the class should be named FOPFactory instead. Same for Fop -- FOP (precedent is the java.net.URL class). - If it's the other way around FOPException should be renamed as FopException. - MimeConstants should be renamed as MIMEConstants. - FOURIResolver should probably be renamed as plain URIResolver (the FO prefix may be deemed redundant because of the package), or as FOPURIResolver. Two consecutive acronyms in an identifier are awkward in any case. - Same for FOUserAgent -- UserAgent or FOPUserAgent - The method applyHttpBasicAuthentication should be renamed applyHTTPBasicAuthentication. - Rename the CLI parameter -param to -xsltparam or something (too generic) We could keep and deprecate the unrenamed classes in order to ease the transition. If the API is really declared stable, the beta tag can be dropped from the release number even for a pre 1.0 release. Should we hold a formal vote on the API style issue? Either way, I'd even volunteer to do the changes (it's easy enough :-). J.Pietschmann
Re: Media or paper tray selection in FOP
Jeremias Maerki wrote: We can throw exceptions if no mapping is found, or the stuff is simply printed on the default paper and people will quickly figure out that they've done something wrong. Well, having printed large documents on partly manually fed special paper I know that even small errors can be expensive in both wasted time and raw material. Raising a warning which can be upgraded to an error after analyzing the the layout-master-set in case some mappings aren't found seems to be prudent (some simple may be left unused). Well, I've been persuaded that output media control should be done on the page master level. I'm still somewhat uneasy with the chain of indirections/mappings necessary, these things tend to break unexpectedly. But I don't have a better solution either. J.Pietschmann
Re: Media or paper tray selection in FOP
Jeremias Maerki wrote: Attention: long post. :-) [snip stuff which reminds me on reinventing TeX/DVI] Using the page master name to map onto output media suggests that different page flows could be printed on different media. Is this correct? I don't like the idea of using the name of single-page-masters all that much: people with complicated page sequence masters may easily forget to map one of the used single page masters properly. I'd rather go for declaring the desired output directly on the flow (using an extension attribute), on fo:root for providing a default or in a fo:declarations (extension element). PIs are also an option, they may enhance portability (ignored by other software than the target processor) but may confuse users about the scope where they apply and may provide surprises if read too late in a streaming processing mode. J.Pietschmann
Re: svn commit: r397562 [2/6] - in /xmlgraphics/fop/trunk/src/sandbox: META-INF/services/ org/apache/fop/render/afp/ org/apache/fop/render/afp/apps/ org/apache/fop/render/afp/exceptions/ org/apache/fo
[EMAIL PROTECTED] wrote: Added: .../fop/render/afp/exceptions/NestedRuntimeException.java ^^ Ow. Don't we have that already somewhere else in the code? J.Pietschmann
Re: How about a release?
Jeremias Maerki wrote: [snip] +1 to a new beta release, even if the whitespace still isn't resolved completely. J.Pietschmann
Re: [VOTE] Finalized API - Merge Temp_API_Finalization branch back into Trunk
Jeremias Maerki wrote: 1. I'd like to propose merging back the Temp_API_Finalization branch back into Trunk. +1 2. ... +1 from me for deprecating all Fop constructors, +1 J.Pietschmann
Re: Unicode Alphabetic characters
Jeremias Maerki wrote: Yep, that's exactly what I need. But hey, adding a 3MB library just for this method, that is a little much. If all else fails, do the same as for the line breaking properties. J.Pietschmann
Re: Unicode Alphabetic characters
Simon Pepping wrote: It aims to be _the_ Java access library to Unicode. As FOP becomes more Unicode aware, can we do without it? Perhaps it also has anything on UAX#14, line breaking? It has the tables, but not the algorithm. Java has already the BreakIterator as algorithm implementation, but no direct access to the line breaking properties itself, which thwarts attempts to have an alternative implementation based on already available data :-( Same for BIDI :-(, although Java's interface to the BIDI related algorithms are better than the BreakIterator attempt, fortunately. Is there a way to make it an optional extension to java's Unicode support, to be installed by those users who want to use Unicode features in FOP that go beyond the ordinary? Most such users may already have it installed. I'd go for a pluggable algorithm providers, as already proposed several times for various purposes. Algorithms based on ICU presence could be preferred, while falling back to a more crude implementation if ICU is not presend. BTW ICU has lots of other interesting features relevant for I18N, look for example at the calender section or the number formatting. J.Pietschmann
Re: Unicode Alphabetic characters
Jeremias Maerki wrote: On 28.02.2006 21:48:27 J.Pietschmann wrote: If all else fails, do the same as for the line breaking properties. Sorry, but I don't understand what you mean. Generate the necessary data tables directly from the Unicode source, automatically or manually. Yes, NIH appears to raise its ugly head... J.Pietschmann
Re: Unicode Alphabetic characters
Jeremias Maerki wrote: Did you see that there's a BreakIterator in ICU4J? Ooops, missed that. Thank you for the correction. If you guys tell me that it would be worthwhile to take this library (or parts of it) aboard, I'm fine with it. Well, for line breaking I don't see an advantage over using the Java BreakIterator (other than the latter not being available in Java 1.3). I'd prefer to have a more pull style interface to the line break finder though. J.Pietschmann
Re: Removing the character area tree object
Jeremias Maerki wrote: I'm considering removing the character area tree object and instead map an fo:character to a normal text area with one word child. Looks ok: +1 J.Pietschmann
Re: [Xmlgraphics-fop Wiki] Update of ApiDesign by JeremiasMaerki
Jeremias Maerki wrote: I've addressed your concern and deprecated the use of PDFEncryptionParams in FOUserAgent (D15). Darn quick reaction. I'm impressed! You proposed using a Properties object. The problem I see here is that non-String values cannot be used whereas with the existing renderer options Map this is possible. No problem. I just had a vague memory that properties can automatically convert strings into boolean values. J.Pietschmann
Re: Parsing foreign XML
Jeremias Maerki wrote: Among other things, I'm currently implementing support for XMP metadata ... I introduced the concept of a ContentHandlerFactory (util package). This could also be used when building the FO tree instead of dealing with XMLObj-descendants which are discarded after the DOM element they generate is added to the Document on one of its ancestors. I'm somehow reminded of commons digester, which implements a rule based approach of building a Java object network from XML. Maybe its worth taking a look at its source, or even evaluate the option of using digester to build the FO tree including metadata and embedded foreign data? J.Pietschmann
Re: [Xmlgraphics-fop Wiki] Update of ApiDesign by JeremiasMaerki
Sorry for the delay. Jeremias Maerki wrote: Do you mean something like setOutputProperty(name, value) in the JAXP Transformer? No, rather something like setParam(name,value), but on the renderer. Note that PDF encryption parameters are specific to a rendering run while the character encoding is probably more of a environmental/factory-level config value. After some thinking, I'd say I mean a mechanism for setting or overwriting configuration values from the command line. Something like fop -fo foo.fo -pdf foo.pdf -r noprint=yes -r filters='' (oops, convoluted example), and the name/value pairs after the -r switch would be passed to the renderer by whatever means, for example by mangling the configuration or, as I tried to suggest, as a Properties object. I'm bothered with having a very renderer specific data class in the UserAgent, and no obvious way to pass command line values to the renderer. BTW: encryption options like noprint should as well be configurable, and there are arguments that even the user password for encryption could benefit from being read from the XML configuration data. J.Pietschmann
Re: PDF optimization / linearization AKA web-enabled PDFs
Parker, Les wrote: I am looking for a java class to web-enable PDF files. Does anyone know of such an animal that is Open Source? Check SourceForge. IIRC iText and PDFBox both can be configured to generate linearized PDF. J.Pietschmann
Re: Issues with layout engine test framework
Manuel Mall wrote: Personally I would prefer the other way around - people behind non transparent proxies can disable the testcase. The problem is that it appears the whole testsuite to hang, until the connection times out. We could probably exchange arguments ad infinitum. Maybe a solution is to create another category of tests, tests unsafe for people without internet connection or so. J.Pietschmann
Re: Issues with layout engine test framework
Jeremias Maerki wrote: Given that this has come up a number of times in the past, that's not a bad idea. I'll add it to the Wiki. Design idea: create an URL resolver which uses j-c-httpclient and is optionally built. This should resolve all other problems regarding HTTP URLs, including other authorization and session problems. J.Pietschmann
Re: svn commit: r348437 - in /xmlgraphics/fop/trunk/src/documentation: content/xdocs/knownissues.xml content/xdocs/site.xml resources/stylesheets/disabled-testcases2document.xsl sitemap.xmap
[EMAIL PROTECTED] wrote:
Added:
xmlgraphics/fop/trunk/src/documentation/resources/stylesheets/disabled-testcases2document.xsl
Nice to see this!
However:
+ xsl:if test=boolean(name)xsl:text (/xsl:textxsl:value-of
select=name/)/xsl:if:br/
The current names are generated from the file names. I'd welcome any
improvements.
+ xsl:template match=reference
+br/
+See also: a href={.}xsl:value-of select=.//a
The references have been generated too, and there are two
invalid references now. I was unable to locate the specific bugs
(dind't try hard though), can somebody please correct them?
J.Pietschmann
Re: Issues with layout engine test framework
Jeremias Maerki wrote: - There is no easy notification if a disabled test case really is a testcase... Well, we don't have to add safety checks for every little detail, do we? I wouldn't have noticed if I hadn't already been bitten by this. - The external-graphics_src_url testcase Suggestions? Should we just remove it? I've disabled it. People without restrictions could reenable the testcase for themselves. Alternatively, we could add FOP extensions allowing for proxy authentification. J.Pietschmann
Re: svn commit: r345474 - in /xmlgraphics/fop/trunk: ./ test/fotree/ test/java/org/apache/fop/layoutengine/ test/layoutengine/
Manuel Mall wrote: Ooops, that wasn't very efficient as I did more or less the same thing. Oops, sorry. After several weeks of inactivity I thought I could polish up the old sketch and commit. There's still enough work to do though, see the separate post. J.Pietschmann
Re: Linebreaks around e-g and i-f-o
Manuel Mall wrote: What's the opinion around the group on how external-graphics / instream-foreign-objects are suppose to be handled with respect to determining linebreak opportunities. FOP 0.20.5 implemented b). I read the UAX14 catch all rule LB20 the way that it also recommends b). J.Pietschmann
Re: Leading/trailing space removal in LineLM
Luca Furini wrote: note that a word with a soft hyphen in its middle would not be hyphenated, unless we ignore this character when collecting word fragments Well, in order to prepare for hyphenation, other characters like joiners has to be removed too. We should probably also use Unicode normalization. J.Pietschmann
Re: zero width space
Manuel Mall wrote: What about character composition/decomposition? Good question? Where is the answer? Lets clarify the problem first. Let's say the input contains the sequence U+0061 U+0308 (latin small a, combining diaresis), the font has a glyph for U+00E4 but not U+0308. Obviously, putting the precomposed character U+00E4 into the output is a smart move. Where should this transformation occur: output generation, renderer, layout stage? A slight problem is that the width of U+00E4 may be different from U+0061. J.Pietschmann
