DO NOT REPLY [Bug 37165] - fo:block id=x span=all
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=37165. 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=37165 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-10-24 08:06 --- The problem is due to reprocessing the block with the id by the column balancing caused by the span=all block. There is no workaround other than removing the id or not using span=all blocks. *** This bug has been marked as a duplicate of 14962 *** -- 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: Space resolution - ready for merge
I'm going to do the merge today. Big thanks to Simon for doing a review on my stuff!!! On 20.10.2005 21:15:44 Simon Pepping wrote: On Wed, Oct 19, 2005 at 03:13:53PM +0200, Jeremias Maerki wrote: I'm comfortable now with the space resolution code. If it's ok for everybody, I'd like to merge the space resolution branch into Trunk. I've documented the open issues I know. All these issues have a (disabled) test case to demonstrate the problem. The only thing that I will probably do right now is clean up a few LM since I've only commented older code passages dealing with spaces. I agree that the code is ready to be merged into the trunk. Jeremias Maerki
Re: Space resolution - merged
Weird, the space resolution branch is merged into trunk since over two hours but the commit message hasn't shown up. Anyway, this is the revision: http://svn.apache.org/viewcvs.cgi?diff_format=hrev=328010view=rev All revisions done in the branch: svn log -r 320826:327988 http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_SpaceResolution/ On 24.10.2005 09:57:26 Jeremias Maerki wrote: I'm going to do the merge today. Big thanks to Simon for doing a review on my stuff!!! On 20.10.2005 21:15:44 Simon Pepping wrote: On Wed, Oct 19, 2005 at 03:13:53PM +0200, Jeremias Maerki wrote: I'm comfortable now with the space resolution code. If it's ok for everybody, I'd like to merge the space resolution branch into Trunk. I've documented the open issues I know. All these issues have a (disabled) test case to demonstrate the problem. The only thing that I will probably do right now is clean up a few LM since I've only commented older code passages dealing with spaces. I agree that the code is ready to be merged into the trunk. Jeremias Maerki Jeremias Maerki
DO NOT REPLY [Bug 37116] - ESC POS Renderer
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=37116. 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=37116 --- Additional Comments From [EMAIL PROTECTED] 2005-10-24 15:01 --- uups.. 283 instead of 284 for TM-L90... -- 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 37116] - ESC POS Renderer
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=37116. 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=37116 --- Additional Comments From [EMAIL PROTECTED] 2005-10-24 15:06 --- Off course Jeremias, i'll doit as soon as i can. -- 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 37219] New: - keep.together.within-page=always is not working
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=37219. 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=37219 Summary: keep.together.within-page=always is not working Product: Fop Version: 0.20.5 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] We need to use keep.together.within-page=always with fo:table-row and fo:table- cell, but it is not working with either. -- 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 37219] - keep.together.within-page=always is not working
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=37219. 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=37219 --- Additional Comments From [EMAIL PROTECTED] 2005-10-24 15:31 --- And please be careful: It's not keep.together, it's keep-together!!! -- 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 37116] - ESC POS Renderer
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=37116. 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=37116 --- Additional Comments From [EMAIL PROTECTED] 2005-10-24 16:25 --- Created an attachment (id=16788) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16788action=view) escposrenderer with apache header and package 1) modified package 2) added apache header i'll clean it for newer fop versions.. -- 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 37116] - ESC POS Renderer
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=37116. 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=37116 --- Additional Comments From [EMAIL PROTECTED] 2005-10-24 16:53 --- (In reply to comment #2) Andrea, thank you for this. I think support for these POS printers is interesting, though I'm not sure this is the best approach to implement this. I think you could create a much more universally usable thing if you took the bitmap conversion out of the renderer and into a separate package where you simply take bitmap images that you convert for the POS printers. That way it could easily be used for FOP Trunk, too. Yes, but is really useless without FOP. Those printers are almost used to print receipts and invoices, with near to 0 support for advanced imaging, so this will be used almost to line up text on preprinted forms, and i think it is a very easy way to do it. After all, we won't be able to include your renderer in FOP as is, (1) because it's apparently written for FOP 0.20.5 whose development line has been frozen and (2) your code would need some touch-up before we would include it (code style, package name must be org.apache.fop.*, no apache license header etc.). I posted it with package and header, but is there a doc with coding style infos that i can use to touch-up the code? Which branch i should use? If I were you, separate this code out into a universally usable component that can convert bitmaps to output for POS printers and post that somewhere on the net, for example as SourceForge project. We could then link to it from the FOP website. WDYT? As i say i think it is really useless alone. Thanks Andrea -- 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: Simplifying the configuration file
On Oct 24, 2005, at 16:10, Jeremias Maerki wrote: I'm currently documenting the new configuration layout. I must say it feels a little awkward right now. Does anybody mind if I simplify it a little in the following way? Not at all. +1 Cheers, Andreas
Re: Simplifying the configuration file
Looks like welcome changes to me! (although I believe dpi is really 'dots per inch' instead of dots per pixel) +1 On Oct 24, 2005, at 7:10 AM, Jeremias Maerki wrote: I'm currently documenting the new configuration layout. I must say it feels a little awkward right now. Does anybody mind if I simplify it a little in the following way? Old: fop version=1.0 base url=.// !-- pixel to millimeter to specify dpi, 72dpi -- pixelToMillimeter value=0.3528/ pagesettings !-- default page-height and page-width, in case value is specified as auto -- pageHeight value=11in/ pageWidth value=8.26in/ /pagesettings New: fop version=1.0 !-- Base URL for resolving relative URLs -- base.//base !-- Internal resolution in dpi (dots per pixel), default: 72dpi -- resolution72/resolution !-- default page-height and page-width, in case value is specified as auto -- default-page-settings height=11in width=8.26in/ I think no mortal prefers pixelToMillimeter over a resolution value in dpi. The value can easily converted to pixelToMillimeter internally. Jeremias Maerki 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: Simplifying the configuration file
It is a matter of taste if one uses base url=.// or base.//base. Either is OK with me, but I do not like seeing it going backward and forward. Anyway, I suggest base-url.//base-url. Giving the resolution in dpi is much better. Simon On Mon, Oct 24, 2005 at 04:10:46PM +0200, Jeremias Maerki wrote: I'm currently documenting the new configuration layout. I must say it feels a little awkward right now. Does anybody mind if I simplify it a little in the following way? Old: fop version=1.0 base url=.// !-- pixel to millimeter to specify dpi, 72dpi -- pixelToMillimeter value=0.3528/ pagesettings !-- default page-height and page-width, in case value is specified as auto -- pageHeight value=11in/ pageWidth value=8.26in/ /pagesettings New: fop version=1.0 !-- Base URL for resolving relative URLs -- base.//base !-- Internal resolution in dpi (dots per pixel), default: 72dpi -- resolution72/resolution !-- default page-height and page-width, in case value is specified as auto -- default-page-settings height=11in width=8.26in/ I think no mortal prefers pixelToMillimeter over a resolution value in dpi. The value can easily converted to pixelToMillimeter internally. Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: svn commit: r328145 - in /xmlgraphics/fop/trunk: conf/fop.xconf src/java/org/apache/fop/apps/FOUserAgent.java
On Oct 24, 2005, at 21:48, [EMAIL PROTECTED] wrote:
Author: jeremias
Date: Mon Oct 24 12:48:37 2005
New Revision: 328145
It's all the same to me. I added the below line for the sole purpose
of validating the URL:
-URL cfgBaseURL = new URL(cfgBaseDir);
But if it goes, then this one should go as well, I think
} catch (MalformedURLException mue) {
log.error(Base URL in user config is malformed!);
After all, currently it serves no purpose anymore...
Cheers,
Andreas
DO NOT REPLY [Bug 37236] New: - Fix gradients and patterns
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=37236. 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=37236 Summary: Fix gradients and patterns Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: svg AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] This is a bug to hold work on fixing the gradient and pattern support for PDF output from Batik. -- 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 37236] - Fix gradients and patterns
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=37236. 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=37236 --- Additional Comments From [EMAIL PROTECTED] 2005-10-25 03:47 --- Created an attachment (id=16800) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16800action=view) Update that support patterns with overflow=visible This version of the patch supports overflow on patterns but it requires the SVN version of Batik as I needed to add access to the 'overflow' member of the PatternPaint class. For this reason I didn't obsolete the previous patch. -- 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.
