[jira] [Created] (FOP-2383) [patch] table cells inherit inline styles from preceding pages.
Michael Hombre Brinkmann created FOP-2383: - Summary: [patch] table cells inherit inline styles from preceding pages. Key: FOP-2383 URL: https://issues.apache.org/jira/browse/FOP-2383 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 1.1 Reporter: Michael Hombre Brinkmann Priority: Minor If in a table cell a style bold, italic, strikethrough, underline, super or sub is given, these styles are applied to all subsequent cells of the same row. The given patch only solves the problems for the 6 given styles. It can be probably enhanced to fix also issures #FOP-2225 and #FOP-1487. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2383) [patch] table cells inherit inline styles from preceding cells.
[ https://issues.apache.org/jira/browse/FOP-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hombre Brinkmann updated FOP-2383: -- Summary: [patch] table cells inherit inline styles from preceding cells. (was: [patch] table cells inherit inline styles from preceding pages.) [patch] table cells inherit inline styles from preceding cells. --- Key: FOP-2383 URL: https://issues.apache.org/jira/browse/FOP-2383 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 1.1 Reporter: Michael Hombre Brinkmann Priority: Minor Attachments: rtf-table-inline-attribute-patch.diff If in a table cell a style bold, italic, strikethrough, underline, super or sub is given, these styles are applied to all subsequent cells of the same row. The given patch only solves the problems for the 6 given styles. It can be probably enhanced to fix also issures #FOP-2225 and #FOP-1487. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2383) [patch] table cells inherit inline styles from preceding cells.
[ https://issues.apache.org/jira/browse/FOP-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hombre Brinkmann updated FOP-2383: -- Description: If in a table cell a style bold, italic, strikethrough, underline, super or sub is given, these styles are applied to all subsequent cells of the same row. The given patch only solves the problems for the 6 named styles. It can be probably enhanced to fix also issures #FOP-2225 and #FOP-1487. was: If in a table cell a style bold, italic, strikethrough, underline, super or sub is given, these styles are applied to all subsequent cells of the same row. The given patch only solves the problems for the 6 given styles. It can be probably enhanced to fix also issures #FOP-2225 and #FOP-1487. [patch] table cells inherit inline styles from preceding cells. --- Key: FOP-2383 URL: https://issues.apache.org/jira/browse/FOP-2383 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 1.1 Reporter: Michael Hombre Brinkmann Priority: Minor Attachments: rtf-table-inline-attribute-patch.diff If in a table cell a style bold, italic, strikethrough, underline, super or sub is given, these styles are applied to all subsequent cells of the same row. The given patch only solves the problems for the 6 named styles. It can be probably enhanced to fix also issures #FOP-2225 and #FOP-1487. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2383) [patch] table cells inherit inline styles from preceding cells.
[ https://issues.apache.org/jira/browse/FOP-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Hombre Brinkmann updated FOP-2383: -- Attachment: rtf-table-inline-attribute-patch.diff [patch] table cells inherit inline styles from preceding cells. --- Key: FOP-2383 URL: https://issues.apache.org/jira/browse/FOP-2383 Project: Fop Issue Type: Bug Components: renderer/pdf Affects Versions: 1.1 Reporter: Michael Hombre Brinkmann Priority: Minor Attachments: rtf-table-inline-attribute-patch.diff If in a table cell a style bold, italic, strikethrough, underline, super or sub is given, these styles are applied to all subsequent cells of the same row. The given patch only solves the problems for the 6 named styles. It can be probably enhanced to fix also issures #FOP-2225 and #FOP-1487. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: JIRA Component Labels
The only doc I've found was in Bugzilla (see [1]). Your refactor is certainly more appropriate, regarding FOP new design (I mean post v0.2x, hehe). [1] https://issues.apache.org/bugzilla/describecomponents.cgi?product=Fop%20-%20Now%20in%20Jira 2014-05-27 10:09 GMT+02:00 Glenn Adams gl...@skynav.com: Perhaps. However, I'm not aware of any documentation for the prior component labeling system. Please point me at it if you know otherwise. I will endeavor to follow up with documentation of the more elaborate componentization when an opportunity arises. In the mean time, if you feel the urge, please feel free to write something. On Tue, May 27, 2014 at 4:00 PM, Pascal Sancho psancho@gmail.com wrote: Hi Glenn, Such info should be available either on website or on wiki, shouldn't it? 2014-05-27 6:31 GMT+02:00 Glenn Adams gl...@skynav.com: Additional minor changes: fonts/* changed to font/* images/* changed to image/* Added: foreign/barcode foreign/svg There are now 3 SVG components: foreign/svg - for SVG input via instream-foreign-object image/svg - for SVG input via external-graphic renderer/svg - for SVG output On Tue, May 27, 2014 at 9:56 AM, Glenn Adams gl...@skynav.com wrote: I have long been unsatisfied with the set of component labels previously used with Bugzilla, which we inherited in JIRA. I've finally gotten around to relabeling many of the existing components and adding more specific components. I have relabeled as follows: awt renderer : renderer/awt fo tree : fo/unqualified fonts : fonts/unqualified general : unqualified images : images/unqualified page-master/layout : layout/unqualified pcl : renderer/pcl pdf : renderer/pdf ps : renderer/ps rtf : renderer/rtf svg : renderer/svg I have added the following: fo/block fo/inline fo/page fonts/opentype fonts/postscript images/jpeg images/png images/tiff images/svg layout/block layout/inline layout/line layout/page renderer/afp renderer/txt When you edit an existing issue, if its component contains unqualified, then please take the opportunity to review and preferably select a more qualified component name. If you don't find a suitably named alternative, then please suggest one to this list so I can add it. Note also, regarding the former svg component, I have relabeled that as renderer/svg, which may not be appropriate depending on the issue. If the issue is related to input from SVG (as opposed to output to SVG), then I have created the images/svg component for the issues related to SVG input. -- pascal -- pascal
Re: Why integrating DITA into XMLGraphics makes sense.
Hi Ron, I agree that some education of both parties is needed. Its no longer true that FOP is a buggy limited piece of software. That might have been true 3-4 years ago, but it is becoming a very mature product now. That is a clear sign that the DITA experts are out of date. We need to work with the DITA experts to keep them informed of progress. Also input from the DITA experts on the top 10 missing features or bugs would be helpful for us in prioritizing work too. Of course, DITA folks might see a solution in XEP or Antenna house, but both are expensive, and the last time I checked AH only supports PDF output, not PS or AFP. Thanks, Chris On 25/05/2014 15:40, Ron Wheeler wrote: A good starting point: http://thecontentwrangler.com/2008/04/11/choosing_an_xml_schema_docbook_or_dita/ A good discussion about how DITA-OT uses XSL and XSL-FO to create PDF from DITA XML. http://www.scriptorium.com/whitepapers/ditaotpdf/DITA-PDF-tweaks.pdf I am trying to get the FOP side to be aware of the importance of DITA as a standard for documentation so the FOP developers will pay some attention to the needs for improved FOP features and perhaps give advice to the DITA-OT developers to use FOP in the best possible way. I am trying to get the DITA side to stop considering FOP to be a static thing that can not be changed and to start to contribute ideas and funding to make FOP do the things that it needs to do. I also want to encourage the DITA-OT team to enter into discussions with the FOP experts to make sure that DITA-OT uses FOP in the best possible way. This problem with the leading dots is a good example of the problem. When the problem was raised by a documentation author, one of the leading DITA experts proposed the solution to the problem was to stop trying to make FOP work since it is buggy and inconsistent rather than suggesting that the user ask the question in the FOP user forum. When I brought the problem here, an answer was provided that looks like a simple change to DITA-OT's FOP configuration that seemed to be a solution to this problem that is well understood here. Ron On 24/05/2014 9:22 PM, Glenn Adams wrote: I'm not familiar with DITA, but if a DITA product depends on FOP, then DITA as a group or its sponsors should consider funding the work they would like to see done in FOP. Simply asking the few developers in the FOP project to support DITA priorities won't guarantee any results. On Sun, May 25, 2014 at 5:38 AM, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: You are right , of course. However, this very large community ( one DITA LinkedIn group has 4,600 members, the Technical Doc group has over 14,000 members) does not see themselves as users of FOP but only as users of DITA-OT which in turn has a dependency on FOP. As far as I know DITA is the most popular XML language for constructing documents and it seems odd that there is almost no connection between the Apache efforts in XML and the biggest potential set of users and drivers of demand for the things that XMLGraphics is producing. I will pass on the information to the forum where the question was raised. Thanks On 23/05/2014 6:05 PM, Luis Bernardo wrote: I think this only shows that the person is not going to the source (i.e., the FOP user mailing list) to request help. The example shown can be greatly improved by using fo:leader width=100% leader-pattern=use-content./fo:leader instead of fo:leader leader-pattern=dots / The FOP implementation repeats 3 dots (...) when using the leader-pattern=dots which is not very intelligent since it can lead to misalignment many times. But by specifying the leader content as just one dot the result can be greatly improved, although I agree that there is room for improvement in this feature. On 5/23/14, 4:14 PM, Ron Wheeler wrote: The conversation below shows one of the reasons why I would like to see DITA become part of the XMLGraphics family. One of the most experienced and influential DITA practitioners is giving advice about the suitability of FOP for producing correct PDFs. Ron - This is an issue with the FOP XSL-FO engine (one of many). For top-qualify PDF output you really need to license Antenna House XSL Formatter or RenderX XEP, both of which produce excellent results. FOP simply has too many bugs and limitations to be generally useful for production PDF generation using XSL-FO, unfortunately. Cheers, XXX On 5/23/14, 9:54 AM, yyy [dita-users] dita-us...@yahoogroups.com mailto:dita-us...@yahoogroups.com wrote: [Attachment(s) #TopText from Mark Peters included below] Hi, Using DITA-OT 1.7 and the default org.dita.pdf2 plugin, I
[jira] [Updated] (FOP-2383) [patch] table cells inherit inline styles from preceding cells.
[ https://issues.apache.org/jira/browse/FOP-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Sancho updated FOP-2383: --- Component/s: (was: renderer/pdf) renderer/rtf [patch] table cells inherit inline styles from preceding cells. --- Key: FOP-2383 URL: https://issues.apache.org/jira/browse/FOP-2383 Project: Fop Issue Type: Bug Components: renderer/rtf Affects Versions: 1.1 Reporter: Michael Hombre Brinkmann Priority: Minor Attachments: rtf-table-inline-attribute-patch.diff If in a table cell a style bold, italic, strikethrough, underline, super or sub is given, these styles are applied to all subsequent cells of the same row. The given patch only solves the problems for the 6 named styles. It can be probably enhanced to fix also issures #FOP-2225 and #FOP-1487. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: JIRA Component Labels
A similar set of descriptions are available at [1] for the JIRA FOP project. [1] https://issues.apache.org/jira/browse/FOP/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel On Tue, May 27, 2014 at 8:43 PM, Pascal Sancho psancho@gmail.comwrote: The only doc I've found was in Bugzilla (see [1]). Your refactor is certainly more appropriate, regarding FOP new design (I mean post v0.2x, hehe). [1] https://issues.apache.org/bugzilla/describecomponents.cgi?product=Fop%20-%20Now%20in%20Jira 2014-05-27 10:09 GMT+02:00 Glenn Adams gl...@skynav.com: Perhaps. However, I'm not aware of any documentation for the prior component labeling system. Please point me at it if you know otherwise. I will endeavor to follow up with documentation of the more elaborate componentization when an opportunity arises. In the mean time, if you feel the urge, please feel free to write something. On Tue, May 27, 2014 at 4:00 PM, Pascal Sancho psancho@gmail.com wrote: Hi Glenn, Such info should be available either on website or on wiki, shouldn't it? 2014-05-27 6:31 GMT+02:00 Glenn Adams gl...@skynav.com: Additional minor changes: fonts/* changed to font/* images/* changed to image/* Added: foreign/barcode foreign/svg There are now 3 SVG components: foreign/svg - for SVG input via instream-foreign-object image/svg - for SVG input via external-graphic renderer/svg - for SVG output On Tue, May 27, 2014 at 9:56 AM, Glenn Adams gl...@skynav.com wrote: I have long been unsatisfied with the set of component labels previously used with Bugzilla, which we inherited in JIRA. I've finally gotten around to relabeling many of the existing components and adding more specific components. I have relabeled as follows: awt renderer : renderer/awt fo tree : fo/unqualified fonts : fonts/unqualified general : unqualified images : images/unqualified page-master/layout : layout/unqualified pcl : renderer/pcl pdf : renderer/pdf ps : renderer/ps rtf : renderer/rtf svg : renderer/svg I have added the following: fo/block fo/inline fo/page fonts/opentype fonts/postscript images/jpeg images/png images/tiff images/svg layout/block layout/inline layout/line layout/page renderer/afp renderer/txt When you edit an existing issue, if its component contains unqualified, then please take the opportunity to review and preferably select a more qualified component name. If you don't find a suitably named alternative, then please suggest one to this list so I can add it. Note also, regarding the former svg component, I have relabeled that as renderer/svg, which may not be appropriate depending on the issue. If the issue is related to input from SVG (as opposed to output to SVG), then I have created the images/svg component for the issues related to SVG input. -- pascal -- pascal
Re: JIRA Component Labels
I missed it. I was remembering about Bugzilla, but didn't get the idea to look into Jira, my bad. 2014-05-27 15:02 GMT+02:00 Glenn Adams gl...@skynav.com: A similar set of descriptions are available at [1] for the JIRA FOP project. [1] https://issues.apache.org/jira/browse/FOP/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel On Tue, May 27, 2014 at 8:43 PM, Pascal Sancho psancho@gmail.com wrote: The only doc I've found was in Bugzilla (see [1]). Your refactor is certainly more appropriate, regarding FOP new design (I mean post v0.2x, hehe). [1] https://issues.apache.org/bugzilla/describecomponents.cgi?product=Fop%20-%20Now%20in%20Jira 2014-05-27 10:09 GMT+02:00 Glenn Adams gl...@skynav.com: Perhaps. However, I'm not aware of any documentation for the prior component labeling system. Please point me at it if you know otherwise. I will endeavor to follow up with documentation of the more elaborate componentization when an opportunity arises. In the mean time, if you feel the urge, please feel free to write something. On Tue, May 27, 2014 at 4:00 PM, Pascal Sancho psancho@gmail.com wrote: Hi Glenn, Such info should be available either on website or on wiki, shouldn't it? 2014-05-27 6:31 GMT+02:00 Glenn Adams gl...@skynav.com: Additional minor changes: fonts/* changed to font/* images/* changed to image/* Added: foreign/barcode foreign/svg There are now 3 SVG components: foreign/svg - for SVG input via instream-foreign-object image/svg - for SVG input via external-graphic renderer/svg - for SVG output On Tue, May 27, 2014 at 9:56 AM, Glenn Adams gl...@skynav.com wrote: I have long been unsatisfied with the set of component labels previously used with Bugzilla, which we inherited in JIRA. I've finally gotten around to relabeling many of the existing components and adding more specific components. I have relabeled as follows: awt renderer : renderer/awt fo tree : fo/unqualified fonts : fonts/unqualified general : unqualified images : images/unqualified page-master/layout : layout/unqualified pcl : renderer/pcl pdf : renderer/pdf ps : renderer/ps rtf : renderer/rtf svg : renderer/svg I have added the following: fo/block fo/inline fo/page fonts/opentype fonts/postscript images/jpeg images/png images/tiff images/svg layout/block layout/inline layout/line layout/page renderer/afp renderer/txt When you edit an existing issue, if its component contains unqualified, then please take the opportunity to review and preferably select a more qualified component name. If you don't find a suitably named alternative, then please suggest one to this list so I can add it. Note also, regarding the former svg component, I have relabeled that as renderer/svg, which may not be appropriate depending on the issue. If the issue is related to input from SVG (as opposed to output to SVG), then I have created the images/svg component for the issues related to SVG input. -- pascal -- pascal -- pascal
[jira] [Commented] (FOP-1099) footnotes within tables and listsl get lost
[ https://issues.apache.org/jira/browse/FOP-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010335#comment-14010335 ] Matthias Reischenbacher commented on FOP-1099: -- I was preparing for hours and hours of debugging FOP internals :-), when I found your patch, Simon. Thanks a lot! It worked perfectly. footnotes within tables and listsl get lost --- Key: FOP-1099 URL: https://issues.apache.org/jira/browse/FOP-1099 Project: Fop Issue Type: Bug Components: layout/unqualified Affects Versions: trunk Environment: Operating System: other Platform: Other Reporter: gerhard oettl Attachments: b37579.diff, b37579.diff, b37579_2.patch, bugzilla37579.patch, dorfchronik.fo, dorfchronik.fo.list3, dorfchronik.fo.table3, footnote.fo, footnoteintable.patch, footnotes.080502.diff, footnotespatch, fussnote.fo, table_list_footnotes.diff, vtest.fo Footnote outside of tables works, inside table-cell not. The compliance page only speaks about restrictions within multicolumn documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
