Re: Issues with layout engine test framework
On 23.11.2005 21:44:29 J.Pietschmann wrote: snip/ - 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. 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. Jeremias Maerki
Re: Apache FOP on .NET
On 22.11.2005 15:39:24 Dalibor Topic wrote: On Tue, Nov 22, 2005 at 09:12:05AM +0100, Jeremias Maerki wrote: Hi Dalibor Good thing you're still lurking! :-) Well, FOP is very interesting for me in terms of having a free DocBook toolchain on free runtimes that's well maintained. If you are around at FOSDEM, it'd be great to have a small talk about FOP, Batik, XML graphics and free runtimes, what works, what we still need, which areas would need more work, etc. I currently don't have plans for that. But I'll look into it. In the meantime, I'm always available here on the mailing list and via Skype. I've also set up a Wiki page where we can track all the issues involved here. Help is welcome. http://wiki.apache.org/xmlgraphics/GnuClasspathCompatibility snip/ Yup. I was under the impression that the XML graphics project would help work around the most dire problems, though. Right? As much as we can, anyway. I'm working on that. I don't think I'll be able to help improving IKVM. GNU Classpath might be easier to help with, but then I still don't have a clue how to work with GNU Classpath on Windows (Cygwin only coming with GCC 3.x, not 4.0). I haven't had the time to help myself to a true Unix environment, yet. I've got access to two Unix systems, both of which don't have GCC/GCJ installed and I have limited knowledge on unixish systems to simply know how to install additional software (if I'm allowed at all). And then I hate C/C++ and having to apply patches before I can compile some software. :-) So this means that it takes a lot of nerves to go after this. Heh, I know, I know ... I can't build Kaffe on Cygwin without a patched up jikes, with Davanum's patches from CVS, etc... I need to pickup my conversation with Cygwin packagers to see if we can get Kaffe packaged in there. With the recent CVS head it's possible to use Kaffe with GNU Classpath like with JamVM, and other runtimes, but it's still some time to go until I release 1.1.7. I'll play around a bit with gcjx on cygwin, to see if it works better than jikes. Good luck! I'll keep trying myself. snip/ Jeremias Maerki
Re: svn commit: r348291 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/dev/release.xml
Hello, I would suggest you make the announcement on the dita-users list, as well. dita-users is the equivalent of docbook-apps in the DITA world. And the DITA Open Toolkit from sourceforge relies on FOP to make PDFs. [EMAIL PROTECTED] On 11/24/05, Jeremias Maerki [EMAIL PROTECTED] wrote: Thanks, Vincent. I've added it. On 23.11.2005 20:02:54 Vincent Hennebert wrote: The docbook-apps@lists.oasis-open.org may be added. Although an announcement has already been made on this list (see the message attached). Note that Fop 0.20.5 is still much used by Docbook users. IMO Fop 0.90 will be welcome there. Jeremias Maerki
Re: svn commit: r348291 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/dev/release.xml
Martin, since I assume you're on that list, would you do me a favor and just forward it? I didn't know about DITA and don't have enough time let myself flood with mails from yet another mailing list. But I'll add the info to the page so we think about it next time. Thanks! On 24.11.2005 12:45:48 martin jakubik wrote: Hello, I would suggest you make the announcement on the dita-users list, as well. dita-users is the equivalent of docbook-apps in the DITA world. And the DITA Open Toolkit from sourceforge relies on FOP to make PDFs. [EMAIL PROTECTED] On 11/24/05, Jeremias Maerki [EMAIL PROTECTED] wrote: Thanks, Vincent. I've added it. On 23.11.2005 20:02:54 Vincent Hennebert wrote: The docbook-apps@lists.oasis-open.org may be added. Although an announcement has already been made on this list (see the message attached). Note that Fop 0.20.5 is still much used by Docbook users. IMO Fop 0.90 will be welcome there. Jeremias Maerki Jeremias Maerki
DO NOT REPLY [Bug 37557] - missleading error msg from-table-column
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=37557. 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=37557 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-11-24 16:13 --- I fixed it in SVN Trunk: http://svn.apache.org/viewcvs?rev=348749view=rev Thanks for reporting the problem. -- 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.
DO NOT REPLY [Bug 37521] - TableColLength throws misleading exception; s/PercentageBaseContext/PercentBaseContext/
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=37521. 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=37521 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-11-24 16:18 --- Patch applied. Thanks! http://svn.apache.org/viewcvs?rev=348751view=rev -- 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: svn commit: r348291 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/dev/release.xml
Done. On 11/24/05, Jeremias Maerki [EMAIL PROTECTED] wrote: Martin, since I assume you're on that list, would you do me a favor and just forward it? I didn't know about DITA and don't have enough time let myself flood with mails from yet another mailing list. But I'll add the info to the page so we think about it next time. Thanks! On 24.11.2005 12:45:48 martin jakubik wrote: Hello, I would suggest you make the announcement on the dita-users list, as well. dita-users is the equivalent of docbook-apps in the DITA world. And the DITA Open Toolkit from sourceforge relies on FOP to make PDFs. [EMAIL PROTECTED] On 11/24/05, Jeremias Maerki [EMAIL PROTECTED] wrote: Thanks, Vincent. I've added it. On 23.11.2005 20:02:54 Vincent Hennebert wrote: The docbook-apps@lists.oasis-open.org may be added. Although an announcement has already been made on this list (see the message attached). Note that Fop 0.20.5 is still much used by Docbook users. IMO Fop 0.90 will be welcome there. Jeremias Maerki Jeremias Maerki
Re: svn commit: r348747 - /xmlgraphics/fop/trunk/build.xml
Not necessarily. We've called it 0.90alpha1. I'd assume we'd have a 0.90beta or directly a 0.90 (final) first. But I guess that's open for discussion. I don't care too much about it. On 24.11.2005 17:56:23 Christian Geisert wrote: [EMAIL PROTECTED] schrieb: Going back to SVN Trunk mode. [..] - property name=version value=0.90alpha1/ + property name=version value=0.90svn/ Shouldn't this become 0.91svn? -- Christian Jeremias Maerki
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: Text handling in svg files, transcoders
On 24.11.2005 21:27:28 Jeremias Maerki wrote: Hi Vincent On 24.11.2005 21:00:58 Vincent Hennebert wrote: Hi, 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. Whereas it is said on the Fop website [1] that normal PDF text is used when possible (I've tried with the text.svg file provided there). Is that normal? For PDF, this should not be the case. I guess I need to check that again. Prior to the 0.90alpha1 release this was fixed by introducing PDFBridgeContext. For PostScript, this is the case, yes, because I haven't had the time to do the necessary changes, yet. I've just checked: - PDFTranscoder has the text bridge enabled and uses text commands for text where possible. - The same applies to SVG within XSL-FO (PDFSVGHandler) - EPSTranscoder has the text bridge enabled but the PSTextPainter has a bug determining paintable text elements and there's another problem with the Java2D subsystem which paints all text upside down ATM. Now I remember that I've started debugging in this area but obviously I didn't finish. - For SVG in XSL-FO for PostScript output, the text bridge is currently inactive so that all text is rendered as shapes. The upside-down effect doesn't occur in this case. Good summary for myself when I get back to this. :-) snip/ Jeremias Maerki
Whitespace-handling rework :: Incorrect layout tests?
Hi all, While toying around with moving Block.handleWhitespace() elsewhere, I ended up thoroughly revising the whole lot (more on this to follow). FTM, the point is that my current revised version passes all layout tests apart from the following: leader_text-align.xml leader_toc.xml Both for the reason that a space is retained where the checks seem to indicate that they are expected to be dropped. At least, that's what I think... For the first: fo:leader ... / some text A space should be retained here from the linefeed after fo:leader. The second: .../fo:basic-link fo:leader ... / A space should be retained here from the linefeed between the two elements. If I interpret the tests correctly, they don't expect that space in between...? WDYT? Cheers, Andreas
