Re: FOP Release Automation
Hi, The FOP package should not embed the whole website, but only the documentation part, more precisely only the relevant version folder. Currently, FOP doc folder is referenced as svn:externals in FOP repo, resulting on extra irrelevant info, such as other versions, miscellaneous processes, general info, etc. IMHO, FOP versionned doc should be in FOP repo, and Website repo should refer to each FOP versionned doc through svn:externals prop. WDYT? 2014-05-23 5:15 GMT+02:00 Clay Leeds the.webmaes...@gmail.com: Thank you for looking at this, Robert. I'll take a look at MarkDown solutions as well. Cheers! Clay -- My religion is simple. My religion is kindness. - HH The Dalai Lama of Tibet On May 21, 2014, at 2:24 AM, Robert Meyer rme...@hotmail.co.uk wrote: Hi All, I've been asked to look at a way to automate the FOP release process with regards the website documentation. At the moment every new release requires the following: 1) Download the site from SVN 2) Copy the folder containing the latest version's markdown files (1.1 for example) and rename to the new version 3) Go through all the files manually and update all the references from the old to the new version 4) Update any markdown files in the main directory with regard to the current and previous versions. 5) Delete the oldest version folder as we need only mantain the last 3. 6) Check and resubmit all files back to SVN My initial thought would to have a master copy in a separate directory. That copy would contain a tag in place where the version is given which could be substituted by a script of some kind (ant has a facility to do this). The ant script would also perform all of the above tasks so the only thing left to the user will be to check the output and push the new files. The problem I have with this is that SVN is not the only way in which the files can be edited as there is the web interface. If someone were to edit the files from there, the master copies would become out of date and worse, if someone were to perform a release it would overwrite all those changes. I've been recommended to look at markdown extensions but if anyone else has any ideas on the best way to go about this it would be much appreciated. Thanks, Robert Meyer -- pascal
[jira] [Commented] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14007217#comment-14007217 ] Robert Meyer commented on FOP-2354: --- Patch applied: http://svn.apache.org/viewvc?view=revisionrevision=1597112 [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FOP-2354) [PATCH] Subset support for Type 1 fonts
[ https://issues.apache.org/jira/browse/FOP-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Meyer resolved FOP-2354. --- Resolution: Fixed [PATCH] Subset support for Type 1 fonts --- Key: FOP-2354 URL: https://issues.apache.org/jira/browse/FOP-2354 Project: Fop Issue Type: New Feature Components: fonts Affects Versions: trunk Reporter: Robert Meyer Assignee: Robert Meyer Fix For: trunk Attachments: c0419bt_.pfb, fop.xconf, patch.diff, patch.diff, test.fo This patch adds subsetting support to Type 1 fonts. Currently the only two supported output formats for this are PDF and Postscript. -- This message was sent by Atlassian JIRA (v6.2#6252)
Why integrating DITA into XMLGraphics makes sense.
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 wrote: [Attachment(s) #TopText from Mark Peters included below] Hi, Using DITA-OT 1.7 and the default org.dita.pdf2 plugin, I notice that some TOC entries are randomly misaligned slightly. The leader extends one or two extra dots. For example (not sure if the formatting will come through correctly. An image is also attached): Chapter 1: RTI4T System Overview...11 RTI System Diagram.12 System Components...12 RTI Network Diagram...15 Summary of RTI Setup Tasks...15 Like I said, the misalignment is random. It's not all H1s or H2s, for example, which would probably be relatively easy to fix. Even more puzzling, the XSL-FO attributes in the temp files are identical for nodes at the same level that have different alignments. For example, here are two H1-level nodes. The first node is slightly misaligned. But the indent values are identical for both nodes. fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1310 line-height=150% fo:inline end-indent=14ptRTI System Diagram/fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1310/ /fo:inline /fo:basic-link /fo:block /fo:block fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1334 line-height=150% fo:inline end-indent=14pt System Components /fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1334/ /fo:inline /fo:basic-link /fo:block /fo:block I'm viewing the PDFs in Abobe Reader, but that hasn't made a difference in the past. Any idea what's going on? Thanks for any insights. yyy -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Why integrating DITA into XMLGraphics makes sense.
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 wrote: [Attachment(s) #TopText from Mark Peters included below] Hi, Using DITA-OT 1.7 and the default org.dita.pdf2 plugin, I notice that some TOC entries are randomly misaligned slightly. The leader extends one or two extra dots. For example (not sure if the formatting will come through correctly. An image is also attached): Chapter 1: RTI4T System Overview...11 RTI System Diagram.12 System Components...12 RTI Network Diagram...15 Summary of RTI Setup Tasks...15 Like I said, the misalignment is random. It's not all H1s or H2s, for example, which would probably be relatively easy to fix. Even more puzzling, the XSL-FO attributes in the temp files are identical for nodes at the same level that have different alignments. For example, here are two H1-level nodes. The first node is slightly misaligned. But the indent values are identical for both nodes. fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1310 line-height=150% fo:inline end-indent=14ptRTI System Diagram/fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1310/ /fo:inline /fo:basic-link /fo:block /fo:block fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1334 line-height=150% fo:inline end-indent=14pt System Components /fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1334/ /fo:inline /fo:basic-link /fo:block /fo:block I'm viewing the PDFs in Abobe Reader, but that hasn't made a difference in the past. Any idea what's going on? Thanks for any insights. yyy -- Ron Wheeler President Artifact Software Inc email:rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Why integrating DITA into XMLGraphics makes sense.
You get what you pay for. If you want to invest resources to improve FOP, you are free to do so. On Sat, May 24, 2014 at 12:14 AM, Ron Wheeler rwhee...@artifact-software.com 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 markpeters.w...@gmail.com [dita-users]dita-us...@yahoogroups.com 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 notice that some TOC entries are randomly misaligned slightly. The leader extends one or two extra dots. For example (not sure if the formatting will come through correctly. An image is also attached): Chapter 1: RTI4T System Overview...11 RTI System Diagram.12 System Components...12 RTI Network Diagram...15 Summary of RTI Setup Tasks...15 Like I said, the misalignment is random. It's not all H1s or H2s, for example, which would probably be relatively easy to fix. Even more puzzling, the XSL-FO attributes in the temp files are identical for nodes at the same level that have different alignments. For example, here are two H1-level nodes. The first node is slightly misaligned. But the indent values are identical for both nodes. fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1310 line-height=150% fo:inline end-indent=14ptRTI System Diagram/fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1310/ /fo:inline /fo:basic-link /fo:block /fo:block fo:block start-indent=25pt + (1 * 30pt) + 14pt fo:block end-indent=22pt font-size=10pt font-weight=normal last-line-end-indent=-22pt text-align=justify text-align-last=justify text-indent=-14pt fo:basic-link internal-destination=_OPENTOPIC_TOC_PROCESSING_d70e1334 line-height=150% fo:inline end-indent=14pt System Components /fo:inline fo:inline keep-together.within-line=always start-indent=-14pt fo:leader leader-pattern=dots/ fo:page-number-citation ref-id=_OPENTOPIC_TOC_PROCESSING_d70e1334/ /fo:inline /fo:basic-link /fo:block /fo:block I'm viewing the PDFs in Abobe Reader, but that hasn't made a difference in the past. Any idea what's going on? Thanks for any insights. yyy -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
