Re: Dramatic improvement of PDF text painting quality for SVG
Hi Jeremias, Jeremias Maerki [EMAIL PROTECTED] wrote on 11/03/2007 07:22:17 AM: As you may have see, I've reimplemented the PDFTextPainter which is part of the PDFTranscoder. All most all text is now painted using PDF text painting primitives (except for SVG fonts and where filters are used). The advantages: smaller PDF files, better visible quality, copy/paste is possible. This is a great addition. Thanks for taking the time to implement this.
Re: DO NOT REPLY [Bug 41440] - PDFSVGHandler causes missing resource bundle
Hi All, I think this bug should now be fixed in the SVN version of Batik. Please report back quickly if it isn't. [EMAIL PROTECTED] wrote on 01/26/2007 08:22:59 PM: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41440. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41440 Bug 41440 depends on bug 41473, which changed state. Bug 41473 Summary: DefaultBrokenLinkProvider causes MissingResourceException http://issues.apache.org/bugzilla/show_bug.cgi?id=41473 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: FOP Memory issues (fwd from fop-users)
Hi all,
Andreas L Delmelle [EMAIL PROTECTED] wrote on 01/11/2007 05:24:36
PM:
On Jan 11, 2007, at 22:31, J.Pietschmann wrote:
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
Just a quick comment on this, given the above stats you might
consider having a single Object field and switch the type of object
from the actual child (when there is a single child) to a List of
children when there are multiple children:
Object child;
Child getChild(int idx) {
if (child instanceof List) return (Child)((List)child).get(idx);
if (idx != 0) throw new IndexOutOfBoundsException(...);
return (Child)child;
}
int getNumChildren() {
if (child instanceof List) return ((List)child).size();
return 1;
}
I do this in Batik for the ID HashTable which has similar stats
(you might say that the hashtable can only hold one entry but when
dealing with things like DocumentFragments and detached DOM tree's
it get's a little fuzzy what the ID rules really are).
Admittedly the code is a little ugly, but you can hide
it from all but the implementing class.
Just something to think about it might give you a significant
savings (might even be a tad faster...).
Re: [EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
Hi all, Sam Ruby [EMAIL PROTECTED] wrote on 08/15/2006 08:35:08 AM: Project xml-fop-maintenance has an issue affecting its community integration. This issue affects 1 projects, [javac] /x1/gump/public/workspace/xml-fop- maintenance/build/src/org/apache/fop/svg/PDFTranscoder.java:233: getViewTransform(java.lang.String,org.w3c.dom.Element,float,float,org.apache. batik.bridge.BridgeContext) in org.apache.batik.bridge.ViewBox cannot be applied to (java.lang.String,org.w3c.dom.svg.SVGSVGElement,float,float) [javac] Px = ViewBox.getViewTransform(ref, root, width, height); [javac] ^ What do we want to do about this? In trunk this method now takes the BridgeContext (which I'm sure the maintenance code has available) so it can report line numbers in errors. The code will work fine if the BridgeContext is null (just no line numbers). Is there an expectation that fop-maintenance should work with trunk Batik? We could add the old signature (deprecated) that just calls the new signature with 'null' for the BridgeContext.
Re: Images in FOP 0.92beta
Hi Jeremias, Jeremias Maerki [EMAIL PROTECTED] wrote on 07/14/2006 04:26:57 PM: At first, I'd have preferred to avoid an extra thread if possible so I just added a local ReferenceQueue and used poll() to do house-keeping whenever a user agent signs off. I assume you don't have a non-too-frequently called method you could do on-demand house-keeping in, so the thread is probably ok. Well I figure that the thread will just be blocked in queue.remove most of the time unless it has something to do. I don't think there is much overhead for a thread in the types of systems we are targeting (i.e. not small constrained devices). Note that this is one thread that is used for all CleanerThread sub objects (so it's not like you are likely to spawn lots of threads). Some people put the cleaning in the management calls (so you poll the queue when people add/remove elements from the hash). I'm not fond of that as it means you are borrowing a 'strangers' thread to do your work (it just feels ugly). And given that we have Batik in memory anyway FOP could co-use that thread. But since I'd like to avoid dependencies on Batik directly if possible, can we move CleanerThread to XML Graphics Commons and rename it to ReferenceCleanerThread to give it a more speaking name? I was under the impression that most of the stuff in batik.util will find it's way into graphics commons. As for renaming I don't think it's a big deal. The SoftReferenceCache is indeed a little odd, especially the method names. I think I'll skip that one for now. It is meant to be subclassed to provide a strongly typed interface (notice all the '*Impl' methods are protected. So the subclass can provide public versions that take strongly typed parameters. Some other interesting things I observed while playing around for those interested (ATM, I'm still doing the house-keeping without the thread but I might rewrite): SoftReferences are a very powerful tool in Java, I don't think they get enough attention in general. When using weak references (as the current code does but with the fixed behavior) FOP takes around 35 sec on my machine to produce that 182 image PDF. Heap usage is usually around 12MB with peaks to 26MB. The house-keeping after the user agent retires removes around 178 references. Switching to soft references which is actually the recommended type for caches, the heap usage goes up to the 64MB maximum and pretty much stay there. The whole thing takes 29-30 sec average. The house-keeping after the user agent retires removes between 161 and 170 references. So this means the VM actually keeps more references around, only freeing as many as it needs not to run into memory problems. And it runs faster this way. I learned a few things today. :-) I guess that makes it a good day ;) On 14.07.2006 14:35:06 thomas.deweese wrote: Hi all, Just a small comment on HashMaps with weak values: Jeremias Maerki [EMAIL PROTECTED] wrote on 07/13/2006 04:43:07 PM: Ok, so I changed the WeakHashMap to a HashMap and wrapped the values in WeakReferences. Tadaaa! A PDF with 182 JPEG images with a total size of 258 MB is suddenly produced without exceptions using the VM's default heap settings, never going beyond 26MB heap usage. *g* There is a potential problem with this approach that Batik ran into. Unless you go a little further those weak values accumulate in the map. In your case this probably isn't a big deal, but for Batik where there are potentially of thousands (or tens of thousands, think mouse move events) of entries, these 'dead' entries start to add up. As a result Batik has batik.util.CleanerThread. This class has inner classes that subclass the various SoftReference classes with an additional method 'public void cleared()'. This method is called by the CleanerThread when the object the soft reference is point at is cleared from memory (it uses the ReferenceQueue part of soft references). This gives you the hook you need to then de-register the entry from the has table. This is actually an incredibly useful 'addition' to the standard soft reference classes (for example I will often use it to check if classes I think should go to GC really do go to GC). I should also mention that Batik has a class called 'SoftReferenceCache' which is a thread safe implementation of exactly what you just implemented. The interface may seem a little odd but it is designed to ensure that only one party ever has to decode a resource even if multiple threads request it at the same time. Anyway just thought I would add my 2 cents... Jeremias Maerki
Re: Images in FOP 0.92beta
Hi all, Just a small comment on HashMaps with weak values: Jeremias Maerki [EMAIL PROTECTED] wrote on 07/13/2006 04:43:07 PM: Ok, so I changed the WeakHashMap to a HashMap and wrapped the values in WeakReferences. Tadaaa! A PDF with 182 JPEG images with a total size of 258 MB is suddenly produced without exceptions using the VM's default heap settings, never going beyond 26MB heap usage. *g* There is a potential problem with this approach that Batik ran into. Unless you go a little further those weak values accumulate in the map. In your case this probably isn't a big deal, but for Batik where there are potentially of thousands (or tens of thousands, think mouse move events) of entries, these 'dead' entries start to add up. As a result Batik has batik.util.CleanerThread. This class has inner classes that subclass the various SoftReference classes with an additional method 'public void cleared()'. This method is called by the CleanerThread when the object the soft reference is point at is cleared from memory (it uses the ReferenceQueue part of soft references). This gives you the hook you need to then de-register the entry from the has table. This is actually an incredibly useful 'addition' to the standard soft reference classes (for example I will often use it to check if classes I think should go to GC really do go to GC). I should also mention that Batik has a class called 'SoftReferenceCache' which is a thread safe implementation of exactly what you just implemented. The interface may seem a little odd but it is designed to ensure that only one party ever has to decode a resource even if multiple threads request it at the same time. Anyway just thought I would add my 2 cents...
Re: Question about status of Bidi support, and Arabic/Persian shaping!
Hi all, Jeremias Maerki [EMAIL PROTECTED] wrote on 05/05/2006 02:43:26 AM: I think it is preferrable to reuse code from the Java class library if it covers our requirements (among them: maintain JDK 1.3 compatibility). Sadly that means that java.text.Bidi is a little problematic, except if we say that Bidi support is only available under JDK 1.4 but that might complicate the implementation additionally. java.awt.Font.TextLayout does Bidi layout. This is how Batik gets it's display order information. If we can reuse code from our sister project Batik, that's probably better. Introducing an external library will take careful consideration. We have to make sure, among other things, that the licensing situation is ok. You are more than welcome to use Batik code. However all of Batik's text handling is built around the JDK's AttributedString class, which may not be that compatible with FOP's text handling. Please also look through the fop-dev mailing list archives for any discussions around Bidi and UAX#14. I think the two aspects may be closely related. The two are mostly independent in Batik's implementation. On 05.05.2006 01:00:04 Kia Teymourian wrote: Dear developers, I’m interested to use FOP for creating Documentation with complex text layout languages such as Arabic/Persian. I would like to offer my help for the implementation of Bidi Algorithm (Bug 32789) I search on the FOP-User mailing list and found, this discussion. http://www.mail-archive.com/fop-users@xmlgraphics.apache.org/msg01575.html I’ve done the initial steps and establish myself a development environment, and could render a Unicode String for the Arabic Unicode shaping here is the PDF output and the fo file: http://user.cs.tu-berlin.de/~kiat/fop/simple.pdf http://user.cs.tu-berlin.de/~kiat/fop/simple.fo This test PDF output shows that the words in Arabic/Persian should be rendered for ligature glyphs characters Unicode Arabic Presentation form. And there is no problem with the Arabic shaping for Text, RTF output. Is there anyone who works on Bidi implementation? Should the Bidi Implementation be an awt independent solution? Could we use jdk 1.4 and classes like java.text.Bidi or java.awt.font.TextLayout? I looked around for Bidi implementation and found Fribid, http://fribidi.org/wiki/ which is implemented in C. iText project has also some Bidi classes like class com.lowagie.text.pdf.ArabicLigaturizer class com.lowagie.text.pdf.BidiLine class com.lowagie.text.pdf.BidiOrder Or we can use Batik classes like org.apache.batik.gvt.text.ArabicTextHandler.java I think the first point should be the implementation of org.apache.fop.fo.flow.BidiOverride.java org.apache.fop.layoutmgr.inline.BidiLayoutManager.java And then add some classes for the Arabic character shaping like ArabicLigaturizer. The bidi-Override implementation is very useful for some other projects to be able to create Persian/Arabic Documentation with PDF output from DocBook files. Regards, Kia Teymourian Jeremias Maerki
Re: [EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed
Hi guys, What do you want to do about this? Do we need to move these back for you or what? You might also consider tracking the svg11 branch in gump rather than 'trunk'... This might make more sense in the near term anyway as likely if a release of Batik were to happen in the near term there is a good chance it would be the svg11 branch (really 'stable' at this point) rather than the trunk/svg12 branch (new features). Sam Ruby [EMAIL PROTECTED] wrote on 04/01/2006 07:34:31 AM: Project xml-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 21 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: io-01042006.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - [javac] /x1/gump/public/workspace/xml- fop/src/java/org/apache/fop/image/PNGImage.java:57: cannot find symbol [javac] symbol : class PNGRed [javac] location: class org.apache.fop.image.PNGImage [javac] PNGRed red = new PNGRed(stream, param);
Re: Beta release next week?
Hi Jeremias,
Jeremias Maerki [EMAIL PROTECTED] wrote on 12/14/2005 08:33:47 AM:
Given the number of bugs fixed and the feedback we got, I think it
should be safe to do another release tagged beta.
If you want to do this, then we should 'fix' the PDFTranscoder
for SVG text. It appears that the main problem with Batik 1.6 is
that it calls 'registerBridges' in the base class constructor before
the subclass can 'record' it's updated bridges. I believe it is
possible to fix this by replacing:
super(userAgent);
with:
super(init(userAgent, fontInfo, linkTransform))
Where init is more or less:
UserAgent init(UserAgent ua, FontInfo fi, AffineTransform lt) {
this.fontInfo = fi;
this.linkTransform = lt;
return ua;
}
This will not fix all cases (if a new BridgeContext is constructed,
for example to handle an internal SVG image, it will not inherit the
'updated' bridges, for that to work properly people will need the SVN
Batik).
[Having to employ such ugly tactics to get subclass code run before
baseclass constructor code demonstrates how silly the 'super' must
be first - compiler restriction is].
Re: DO NOT REPLY [Bug 37879] - PDF SVG rendering forces stroking text (config setting broken)
Hi Adam, Adam Strzelecki [EMAIL PROTECTED] wrote on 12/13/2005 07:54:13 AM: It should work with the svn versions of /both/ Fop and Batik. You may look at [1] and [2] for details. Alright but I'm using FOP SVN trunk I was trying with both batik-1.6.jar from TRUNK (SVN) and some nigtly of Batik (26.11) and both of the producing stroked fonts for my SVG files. Have a look at: http://pingu.ii.uj.edu.pl/~ono/download/fop-0.90-trunk-svg-bug/ None of your content uses 'simple' text. All of your text uses child tspan's with 'x' 'y' attributes. This falls into the case of complex text so we stroke the text. Consider that I'm not using standard PDF fonts but Garamond TT font embedded (set in fop.xconf). If you are running WinXP you should have them. I don't think it has anything to do with fonts... Regarding the strokeText option, it has not been implemented in the Trunk because its usefulness is doubtful (see [2]). Text will be rendered as text whenever possible, strokes will only be used as fallbacks. Yea this is for sure. I don't see why somebody would like to force stroking... ;)
Re: DO NOT REPLY [Bug 37879] - PDF SVG rendering forces stroking text (config setting broken)
Hi Adam, Adam Strzelecki [EMAIL PROTECTED] wrote on 12/13/2005 08:17:38 AM: None of your content uses 'simple' text. All of your text uses child tspan's with 'x' 'y' attributes. This falls into the case of complex text so we stroke the text. Booo... so we need to stroke tspans ? Tspans with 'x' 'y' attrs yes. Is there any change to handle them also like simple text ? Assuming you mean chance? Yes it is possible but it is _far_ from trivial. A 'tspan' is quite a bit different from 'text' in particular a tspan inherits it's position from previous tspans/text so placement is complex. There are essentially two paths to go down. 1) rewrite the existing SVG text support for PDF, implementing what pieces can be implemented as a series of 'drawString' calls. 2) Rework the PDFGraphics2D to enable proper output from a GlyphVector - or more correctly a custom version of a GlyphVector as the JDK version does not (I think) provide enough information for transcoding. I believe that with FOP 0.20.5 tspans were handled too (however I might be wrong), because PDF generated with old version were OK. I believe the old version ignored all the problems that sub-tspans with x y cause and just rendered them as normal text. This might have 'worked' for your case but is why there was a 'stroke text' option as it would get many cases wrong.
Re: Text handling in svg files, transcoders
Hi Jeremias, Vincent, Jeremias Maerki [EMAIL PROTECTED] wrote on 11/24/2005 03:27:28 PM: On 24.11.2005 21:00:58 Vincent Hennebert wrote: I would need some help to understand how transcoders and text handling within svg should work. o first, when I try to convert some svg that contains text into pdf with Batik (1.6), text is always rendered as strokes, even if it would be possible to render it with pdf text primitives. This was broken in the Batik 1.6 release. I am about to incorporate the pdf-transcoder.jar from the 0.9alpha1 FOP release into the Batik SVN repository. o the strokeSVGText option seems to have disappeared in Fop Trunk. At one point we thought this option would not be necessary. However, I think that we need to reintroduce it to provide a fallback if the special text handling does not produce satisfactory results. The idea behind the various TextElementBridges is that they determine themselves when they can paint text as text and when they have to resort to painting text as shapes. Thomas, what do you think about this topic? Well I think that currently the text bridges do a pretty good job determining if they are capable of drawing text as PDF text and drop back to curves when needed. I would much rather work on catching cases where this doesn't work properly than adding another option. Do you know of cases right now where this doesn't work? o only the PDFTranscoder is distributed with Batik. Is the PSTranscoder broken? Should I adapt it to FOrayFont? It's not broken but has less features and I guess the demand hasn't been that high for pure SVG to EPS conversion. You should treat the EPSTranscoder and the PSTranscoder the same way as the PDFTranscoder. The PSTranscoder has less value than the EPSTranscoders. It was originally intended for use with SVG Print but I never got around to having a closer look at it. If anyone wanted PSTranscoder gone, I wouldn't be upset. As far as I know no one has ever asked for EPS output from Batik.
Re: [VOTE] Release FOP Trunk as FOP 0.90alpha1
+1 Congratulations! Jeremias Maerki [EMAIL PROTECTED] wrote on 11/15/2005 03:14:12 PM: This is it. Just to make it clear again: This is a a release vote and therefore a PMC vote, but every FOP committer is invited to place his vote or raise any objections. Noone gets ignored. Although fop-dev is in the CC, please place your votes on [EMAIL PROTECTED] Even though I haven't fully finished all of the documentation, yet, I'd like to start the vote. I'll have everthing finished by tomorrow evening (CET). I don't intend to do any more code changes, only the last documentation updates. http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR shows the release plan and the status of the proceedings. I know of no legal problems needing attention. The external dependencies are well documented and every JAR in the lib directory is accompanied by its license. Hyphenation files have been removed. The unknown origin of some long-existing example FO files is not a problem IMO. 0.90alpha1 will carry a big warning sign in the README file that the software is a preview release and should not be used in production unless thoroughly tested for the target environment. It is intended to let everybody know that FOP is back in business and to produce feedback on our new piece of software from users that don't (or can't) download the code from SVN. I'd like to propose to release FOP SVN Trunk as version 0.90alpha1. +1 from me, obviously. Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing for the first release
Hi Jeremias, Not to rain on your parade, but doesn't there need to be a vote on fop-dev by committers on the release before bringing it to the PMC? Also doesn't a formal vote need to run at least one full week? I understand your desire to get the release out but... Jeremias Maerki [EMAIL PROTECTED] wrote on 11/14/2005 05:48:36 PM: BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. - do the (PMC) vote on the release. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable?
Re: Preparing for the first release
Hi Jeremias, Jeremias Maerki [EMAIL PROTECTED] wrote on 11/15/2005 08:28:11 AM: In terms of the Apache bylaws the PMC is the only body that can do project decisions [1]. It appears that they are the 'binding body' from the ASF point of view, but as a PMC member I would really like to see an invitation for the collection of other points of view (i.e. a vote on dev/user for a release). In this case I'm sure it will be greeted with enthusiasm, but I'm really hesitant to set precedent based on the 'best case' situation. BTW, this is a topic that's currently discussed on legal-discuss [2]. From a quick read I take away that the ASF requires 3 +1 from PMC members (oddly unvetoable), but that individual PMC's can have additional requirements, such as a positive vote from committers. As chair it appears that this is your call, so I'll just provide my 2 cents. Where did you read this that a vote has to run a full week? AFAIK, the normal period is 72 hours [3]. I think reading 'at least 72 hours' as 'normal period' is a little misleading. It is far to common for people to disappear for a week's vacation meaning that with just 72hrs an issue can come up be voted before someone sipping margarita's in the Bahamas even knows what has happened. I know that Batik always used 1 week for important votes for exactly this reason. It can of course be terminated earlier if all binding voters reply before the time is up. I think it would be worthwhile if everybody here would reread the pages about how the ASF works. There have been quite a few improvements on these pages lately. The board and the members also made up their minds some more aboute certain topics. I think a clear distinction should be made between the minimum required by the ASF and what we think is reasonable. Especially because in my mind the constituent projects under the XML-Graphics PMC are probably more independent than many. To be honest it makes me quite uncomfortable that at least in theory Batik could be 'forced' to have a release by FOP (even in spite of strong objections from the Batik community). Now I don't consider this a serious concern right now but the fact that the passability exists is IMHO bad. Even I should probably reread them again, although as a member I get a lot of that through the members list already. Reading those pages shows, for example, why the XML project had to split up. While we're at it: There are even voices that projects shouldn't micromanage committer sets anymore. For us, that would mean: All Batik committers become FOP committers and vice-versa. But that's for later. So far, it was just a stray comment on one of the lists. Well, once again I think that having shared committership among the xml-graphics-commons packages is a good thing (it's a set of code that is needed/used fairly heavily by both projects), however I think it would be a poor choice to have a common set of committers for the core of FOP and Batik, one would essentially have to 'trust' the other projects committers to have good judgement, and what to do if they violate that trust? They may make good/useful contributions to the other project, so revoking committership may overly harsh (at least for one project). [1] http://www.apache.org/foundation/how-it-works.html#pmc-members [2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ [3] http://www.apache.org/foundation/voting.html On 15.11.2005 13:59:45 thomas.deweese wrote: Hi Jeremias, Not to rain on your parade, but doesn't there need to be a vote on fop-dev by committers on the release before bringing it to the PMC? Also doesn't a formal vote need to run at least one full week? I understand your desire to get the release out but... Jeremias Maerki [EMAIL PROTECTED] wrote on 11/14/2005 05:48:36 PM: BTW, I think I'm through with all the things I wanted to do. What's left now: - write the README/release notes - Create a copy of the xdocs/trunk directory to xdocs/0.90alpha1. - do the (PMC) vote on the release. - tag and release If it's possible I'd like to start the vote tomorrow and do the release around Thursday/Friday. That reasonable? Jeremias Maerki
Re: Unicode compliant Line Breaking
Hi all, Just an FYI, Batik also currently has an implementation of the Unicode TR14 word breaking alg. (org.apache.batik.gvt.flow.TextLineBreak). As far as performance is concerned it should be fairly fast as it is mostly just table based. The Web Maestro [EMAIL PROTECTED] wrote on 10/31/2005 11:04:54 AM: IMO, Unicode conformant line-breaking is an important goal for FOP to achieve. But before I vote, I have a question: On Oct 30, 2005, at 11:25 PM, Manuel Mall wrote: snip 2. I would also like to propose that the Unicode conformant line breaking be implemented using our own pair-table based implementation and not using Java's line breaker, because: Does it make sense to have using our own implementation over Java's 'configurable'? That way, our users could choose whether or not to use it. In my case, we had no need for Unicode, and IIC the extra code would merely serve to hinder FOP's performance increase FOP's memory footprint (unless it's only called when using Unicode). In addition, a future Java implementation could bring a robust (and maintained) Unicode solution. snip 3. Assuming we get enough +1 for the above proposals the first item to decide after that would be: Where should the code live? a) Joerg would like to see it in Jakarta Commons but hasn't got the time to start the project. b) Jeremias suggested XMLGraphics Commons. c) Personally I think it is too early to factor it out. More experience with its design and use cases should be gathered before making it standalone and at this point in time it really only are 2 core Java classes. I would like to suggest that it initially lives under FOP in something like org.apache.fop.text. Should the need and energy levels (= developer enthusiasm) become available later to make this into an Jakarta Commons or XMLGraphics Commons project so be it. I would think it would be best to start it under XML Graphics Commons (as that's where I suspect it will likely end up), and move it if necessary from there. Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: SVG PDFTranscoder broken...
Hi Jeremias, Jeremias Maerki [EMAIL PROTECTED] wrote on 10/19/2005 12:37:56 PM: I see the problem now and I think I found a fix: http://svn.apache.org/viewcvs?rev=326600view=rev The Graphics.create() methods were simply not implemented properly. Right, thanks for fixing it for me. It looks like even with some of the more complex clipping cases everything is right. Back to trying to figure out what's wrong with gradients... ;) On this point any objection if I have it fall back to rasterizing in some cases that I don't think can be represented in PDF (mostly the complex repeat modes)?
SVG PDFTranscoder broken...
Hi all, I don't know if you want to deal with this here in FOP land or over in Batik land but since the code in question is currently in FOP I thought I would start here. The PDF transcoder is currently broken. This appears to be due to a recent change to the way clips are done. Previously a new clip was done something like: Shape oldClip = g2d.getClip(); // get clip, in the current coordinate system g2d.clip(newAdditiveClip); // Draw things, blah blah g2d.setClip(oldClip); // restore clip, in current coordinate system. This as it turns out has problems, the basic issue is that the clip can 'waver' as it is gotten and restored in various coordinate systems (shift one pixel left or right). To avoid the need to get and restore the clip I started using the 'create' method of the Graphics. So the new code looks something like: g2d = g2d.create(); // create new graphics with independent drawing state g2d.clip(newAdditiveClip); // Draw things, blah blah g2d.dispose(); // parent node will use 'old' graphics 2D. The real code is a bit more complex than this but you get the idea. The problem is that the PDFGraphics2D doesn't seem to properly implement 'create()'. I've tried to hack this in but I get garbage PDF out. So what I'm looking for is a basic analysis of how hard this would be to fix, as well as suggestions on how to fix it. There are some other potential solutions to the wavering clip issue, although I think the above is by far the cleanest (and hence most desirable) of them.
Re: SVG PDFTranscoder broken...
Hi Jeremias, Jeremias Maerki [EMAIL PROTECTED] wrote on 10/18/2005 04:51:00 PM: I recently cleaned up the PDF and PS transcoders so they behave much more similarly. I may have broken clipping then, although I have done quite extensive tests. The problem isn't really with clipping, it's with the 'create' method of the Graphics interface. I was pushed to use 'create' to deal with some clipping issues. Unfortunately, I can't quite follow your problem description. Would you please post an example or describe how I can reproduce the problem? I can then have a look at it. Thanks. I suspect that attempting to render any SVG to PDF with trunk Batik will cause the problem (the root SVG element almost always has an associated clip - which causes the use of create). I was specifically using the test file: samples/tests/spec/paints/linearGradientOrientation.svg from the Batik source tree (I was going to work on fixing PDF Gradients when I noticed the problem). On 18.10.2005 19:28:24 thomas.deweese wrote: Hi all, I don't know if you want to deal with this here in FOP land or over in Batik land but since the code in question is currently in FOP I thought I would start here. The PDF transcoder is currently broken. This appears to be due to a recent change to the way clips are done. Previously a new clip was done something like: Shape oldClip = g2d.getClip(); // get clip, in the current coordinate system g2d.clip(newAdditiveClip); // Draw things, blah blah g2d.setClip(oldClip); // restore clip, in current coordinate system. This as it turns out has problems, the basic issue is that the clip can 'waver' as it is gotten and restored in various coordinate systems (shift one pixel left or right). To avoid the need to get and restore the clip I started using the 'create' method of the Graphics. So the new code looks something like: g2d = g2d.create(); // create new graphics with independent drawing state g2d.clip(newAdditiveClip); // Draw things, blah blah g2d.dispose(); // parent node will use 'old' graphics 2D. The real code is a bit more complex than this but you get the idea. The problem is that the PDFGraphics2D doesn't seem to properly implement 'create()'. I've tried to hack this in but I get garbage PDF out. So what I'm looking for is a basic analysis of how hard this would be to fix, as well as suggestions on how to fix it. There are some other potential solutions to the wavering clip issue, although I think the above is by far the cleanest (and hence most desirable) of them. Jeremias Maerki
ForayFont dependency in graphics commons; was: Logging for FOrayFont
Hi all, So this is a tricky one. I really feel like I'm getting in the way of FOP stuff, but on the other hand as far as I can see the ForayFont stuff would have almost zero advantage for Batik's use of the PDF Transcoder. This is because Batik has to do all of it's own text layout and it currently does this using the Java2D Platform Fonts, TrueType (referenced from CSS), and of course SVG fonts. Right now there are a few 'trivial' text cases that are handled by the PDF Graphics2D 'drawString' stuff that might benefit but basically, as far as I can see, this would - for Batik - be another very low functionality external dependency. That said I know that currently one of the stumbling blocks for extracting the PDFGraphics2D from the rest of FOP is the the font subsystem. There is a bit of an inherent conflict between using Graphics2D as a 'high level transcoding' API and advanced font/text handling. Currently, the list of Java2D fonts (from GraphicsEnvironment is totally independent of the Graphics2D). Now of course the current state of text output for PDF is fairly abysmal from Batik (anything beyond very simple text is done as shapes), but fixing that would probably be a huge piece of work. I personally would lean towards leaving the font-subsystem as pluggable. BTW as far as the PsuedoLogger stuff is concerned this is fine with me (and is actually my preferred way to handle this). It doesn't force any logger on me, yet one can plug it into any existing logging system with a fairly trivial piece of code. Although this may not matter depending on how we approach Font support. Jeremias Maerki wrote: I got a little shock when I realized a problem I didn't think of when we discussed moving FOP components over to XML Graphics Commons. We said we would try to remove logging code from these basic components entirely. Now, I forgot to consider the decision to use FOrayFont made earlier. The external dependency on FOrayFont also would be a problem in itself because the Batik side has strong feelings against external dependencies. We need to think about what to do about this WRT the PDF and PS transcoders. Optimized text painting in these two transcoders depends a lot on the font subsystem. Chris Bowditch wrote: Ouch! The FORayFont integration offers a hugh functional benefit over the current Font code, so it would be a real shame to lose it. IIRC Thomas was saying that he was against dependencies that don't yield any functional benefit, i.e. logging and avalon framework. Since FORayFont does have functional benefits for both projects perhaps it won't be such a problem for Batik to include it. But I guess that is up the Batik team to decide.
Re: DO NOT REPLY [Bug 35918] - [PATCH] Shapes are slightly shifted with respect to lines on larger graphics
I did a few things on PDFGraphics2D to improve the situation: http://svn.apache.org/viewcvs?rev=240344view=rev BTW Batik saw a significant performance increase when we went to using a DecimalFormat object to write our strings.
Re: DO NOT REPLY [Bug 35918] - [PATCH] Shapes are slightly shifted with respect to lines on larger graphics
Jeremias Maerki wrote: Thanks for the hint. Sounds like rewriting PDFNumber.doubleOut using DecimalFormat makes sense. May I ask what you used before switching to DecimalFormat? Double.toString(double d), I just took a look, whats with the PDFNumber.doubleOut function It rounds numbers n+0.05 x n-0.05 to n (where n is an integer)? That seems really hacky ;) Also I can almost assure you that NumberFormat will be _much_ faster than the current code. On 31.08.2005 14:32:01 Thomas DeWeese wrote: I did a few things on PDFGraphics2D to improve the situation: http://svn.apache.org/viewcvs?rev=240344view=rev BTW Batik saw a significant performance increase when we went to using a DecimalFormat object to write our strings. Jeremias Maerki
Re: TIFF images and color model
Manuel Mall wrote: This is probably more a Batik question but as I encountered it in the FOP context and Batik people are on this list here we go: When decoding a TIFF image (black / white fax) using Batik and then looking at the returned color space, e.g. image.getColorModel().getColorSpace(); that color space has a profile of java.awa.color.ICC_ProfileRGB. Well I'm not sure where FOP taps into the Batik image decoders but most likely the _image_ returned is an RGB image in the sRGB color space. Unlike FOP Batik often needs to do significant image processing on the images (filters, compositing etc). As a result we tend to convert as soon as possible into RGBA to simplify later processing. However, I would have expected a color space of ICC_ProfileGray. This is sort of important as the correct color space must be set on the image object in the PDF. I currently set it manually but thats not ideal. The two main options are to either bypass the Batik 'decoding' and use the TIFF image codec directly or to use the TIFF directory to figure out what colorspace the underlying TIFF data is in.
Re: DO NOT REPLY [Bug 36082] - [PATCH] Relative URIs are not correctly resolved
Hi all, On Mon, 15 Aug 2005 08:20 pm, Jeremias Maerki wrote: This is actually not about relative paths, but actual URI resolution. If you look at the JUnit test case I committed earlier [1] I use the URIResolver to resolve an URI funky:myimage123 to one of the bgimg bitmaps in our test directory (a file URL). That's how people can specify abstract URIs instead of concrete URLs to point to resources whose location is not known at deployment time. And it's where XML Commons Resolver jumps in to provide a widely used mapping from URIs to URLs. [1] http://svn.apache.org/viewcvs?rev=232788view=rev Manuel Mall wrote: Alright, this means we need to set the FOP resolver on the SVG processor. Not sure if Batik supports the javax.xml.transform.URIResolver interface. May be any Batik people lurking on this list can shed more light on this? All Batik URL resolution is handled by our ParsedURL implementation. The only 'problem' with the ParsedURL class is that it doesn't have a very direct connection to a UserAgent, so configuration is done on a per JVM (really classloader) basis. So it would be simple to add support for URIResolver in ParsedURL but it wouldn't be a parameter on the 'batik.transcode.Transcoder' class it would be global. I'm not sure if this is a problem or not (I didn't follow all of the discussion above). There is also the potential issue of dragging in a new dependency for an interface with a single method that only takes/returns primitive types. ;)
Re: Batik images and resolution
Jeremias Maerki wrote: Ideally, the *Reader implementations (analyser package) for each format should actually read the extents and the bitmap resolution already. It should not be deferred to the actual codec, if possible. That makes it possible to work with the image (during layout) without fully loading it already. Well IMO the right thing is for the image codec to defer the loading of the image data until requested. This way you only need one set of parsing code to get right and maintain. It can also simply the coding as you don't have to switch between multiple representations. This is the way the imageio classes work. Also some of the Batik codec's work this way (Tiff). Of course, that means that someone has to have a deeper understanding of a bitmap format to be able to write the code that extracts the necessary values. On the other side, the Batik codecs actually parse the resolution information. For PNG, see parse_pHYs_chunk() in [1]. Unfortunately, it doesn't expose that information. Yes it does. It uses the 'properties' interface to expose this (and lots of other) information. The properties in question are x_pixels_per_unit, y_pixels_per_unit pixel_units. The TIFF reader exposes the entire tiff directory (property tiff_directory). You can get the resolution info from that using the constants in TIFFImageDecoder (TIFF_X_RESOLUTION, TIFF_Y_RESOLUTION, TIFF_RESOLUTION_UNIT). It's interesting to note, that PNGImageDecoder [2] does almost the same as PNGRed. That confuses me. Again, PNGImageDecoder doesn't expose the resolution info, either, although it has it. We may need to ask the Batik guys if they know what this is about. This almost screams for a patch. :-) Hmm, I think PNGImageDecoder can be removed, at some point the PNGRed class was created as part of the Batik image hierarchy from the PNGImageDecoder which was donated by Sun. I'm not sure why the PNGImageDecoder wasn't deleted at the time... [1] http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGRed.java [2] http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/apache/batik/ext/awt/image/codec/PNGImageDecoder.java On 12.08.2005 10:56:18 Manuel Mall wrote: I was looking at issues related to images not being displayed with their correct resolution. As far as I understand all image formats apart from GIF (which defaults to 72dpi) do carry resolution information. However, it only works for JPEG at the moment. I managed to fix it for BMP images by reading / interpreting the appropriate header fields. TIFF and PNG are more complicated as the information is buried in the file so you actually have to load the image to get to the information. Both TIFF and PNG are currently implemented using BatikImage. However, it appears that the Batik decoder doesn't make the resolution information available. At least its not set in BatikImage.loadImage() and I couldn't find a field in the org.apache.batik.ext.awt.image.rendered.CachableRed class which looks like holding the x and y resolutions. Any one knows how to get to the resolution settings for the Batik images? Thanks Manuel Jeremias Maerki
[Fwd: svn commit: r219312 ] Batik transcoders now throw errors for missing images
Hi Batik-dev, Fop-dev,
I just wanted to give a heads up on a change to the way
the transcoders work. As the attached commit note mentions
Batik is now forwarding information about 'missing images' to
the UserAgent. This is important because the UserAgent
is an Interface - so if you don't use the UserAgentAdapter
you will have to add the getBrokenLinkDocument method to
your implementation. I strongly suggestion that people use
the Adapter unless you really need the UserAgent as an
interface.
Second I have set up the default UserAgentAdapter to
throw a BridgeException. As a result our transcoders now
throw exceptions when they can not find the image referenced
from an 'image' element. Previously Batik would 'silently'
insert a 'Broken Link' image. The JSVGCanvas now overrides
this behavior to provide a Broken Link image, so it's behavior
should remain unchanged.
This change has been requested several times, and I think
makes a lot more sense for 95% of the uses of the transcoder
classes.
I'm in the processes of merging the changes with the trunk
and verifying nothing breaks.
---BeginMessage---
Author: deweese
Date: Sat Jul 16 03:27:56 2005
New Revision: 219312
URL: http://svn.apache.org/viewcvs?rev=219312view=rev
Log:
1) Handling of broken links is now forwarded to the bridge UserAgent Interface.
This will cause problems if you don't derive off the UserAgentAdapter.
2) The default UserAgentAdapter now throws a BridgeException. As a
result the Transcoders now throw an error when an image can't be
read rather than substituting the broken link document.
3) The JSVGCanvas now provides the BrokenLinkDocument - which should
make it easier for people to customize the behaviour.
4) The JSVGCanvas now has an improved tooltip handling mechanism
(although it still doesn't quite work as desired for the image element).
Added:
xmlgraphics/batik/branches/svg11/resources/org/apache/batik/swing/svg/BrokenLink.svg
- copied unchanged from r209122,
xmlgraphics/batik/trunk/resources/org/apache/batik/bridge/BrokenLink.svg
xmlgraphics/batik/branches/svg11/test-resources/org/apache/batik/dom/svg/bug30580_image.png
(with props)
Removed:
xmlgraphics/batik/branches/svg11/resources/org/apache/batik/bridge/BrokenLink.svg
Modified:
xmlgraphics/batik/branches/svg11/resources/org/apache/batik/bridge/resources/Messages.properties
xmlgraphics/batik/branches/svg11/resources/org/apache/batik/ext/awt/image/spi/resources/Messages.properties
xmlgraphics/batik/branches/svg11/resources/org/apache/batik/swing/svg/resources/Messages.properties
xmlgraphics/batik/branches/svg11/sources/org/apache/batik/bridge/ErrorConstants.java
xmlgraphics/batik/branches/svg11/sources/org/apache/batik/bridge/SVGBrokenLinkProvider.java
xmlgraphics/batik/branches/svg11/sources/org/apache/batik/bridge/SVGImageElementBridge.java
xmlgraphics/batik/branches/svg11/sources/org/apache/batik/bridge/UserAgent.java
xmlgraphics/batik/branches/svg11/sources/org/apache/batik/bridge/UserAgentAdapter.java
xmlgraphics/batik/branches/svg11/sources/org/apache/batik/ext/awt/image/spi/ImageTagRegistry.java
xmlgraphics/batik/branches/svg11/sources/org/apache/batik/gvt/event/AWTEventDispatcher.java
xmlgraphics/batik/branches/svg11/sources/org/apache/batik/swing/JSVGCanvas.java
xmlgraphics/batik/branches/svg11/sources/org/apache/batik/swing/svg/JSVGComponent.java
xmlgraphics/batik/branches/svg11/test-resources/org/apache/batik/swing/unitTesting.xml
Modified:
xmlgraphics/batik/branches/svg11/resources/org/apache/batik/bridge/resources/Messages.properties
URL:
http://svn.apache.org/viewcvs/xmlgraphics/batik/branches/svg11/resources/org/apache/batik/bridge/resources/Messages.properties?rev=219312r1=219311r2=219312view=diff
==
---
xmlgraphics/batik/branches/svg11/resources/org/apache/batik/bridge/resources/Messages.properties
(original)
+++
xmlgraphics/batik/branches/svg11/resources/org/apache/batik/bridge/resources/Messages.properties
Sat Jul 16 03:27:56 2005
@@ -49,8 +49,7 @@
{0}:{1}\n\
Cannot find the referenced element:\n\
{3}\n\
-specified on the element {2} - may be a problem of 'id'
-
+specified on the element {2} - may be a problem of ''id''
uri.io = \
{0}:{1}\n\
@@ -76,8 +75,15 @@
The URI {3}\n\
specified on the element {2} is invalid
-broken.link.title = \
-Broken Link:
+uri.image.broken = \
+{0}:{1}\n\
+The URI {3}\n\
+on element {2} can''t be opened because:\n\
+{4}
+
+uri.image.error = \
+The URI can''t be opened:\n\
+{0}
##
# Messages for DefaultScriptSecurity
Modified:
xmlgraphics/batik/branches/svg11/resources/org/apache/batik/ext/awt/image/spi/resources/Messages.properties
URL:
Re: Foray's font subsystem for Fop
Hi All,
Just to throw in my 2 cents. Batik Handles this through the
@font-face CSS property. This allows you to provide a mapping
from a CSS font-family (with weight etc) to a font file on disk/network
etc:
@font-face { font-family: CSS Batik SVGFont;
src: url(batikFont.svg#Batik); }
Peter B. West wrote:
J.Pietschmann wrote:
Jeremias Maerki wrote:
Ok, but this assumes that you work in concert with AWT's font subsystem.
Well, AWT doesn't provide a way to get the file for a font, but
we can at least get an AWT Font from a TTF file.
And a Type1 file (Java 5). Java just keeps getting better.
This is _very_ interesting. Do you have a reference on this?
Illustrator has a bad habit of embedding CEF (CFF?) fonts in
SVG - these are Type1 font outlines in a TrueType/OpenType wrapper
If the JDK supports Type1 fonts it might support these now as well
(hoping ;).
