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 : > 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 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-tabpanel&focusedCommentId=14007217#comment-14007217 ] Robert Meyer commented on FOP-2354: --- Patch applied: http://svn.apache.org/viewvc?view=revision&revision=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]" 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. RTI System Diagram System Components 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 . instead of 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]" 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. RTI System Diagram System Components 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 > [dita-users]" 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. > > > font-weight="normal" last-line-end-indent="-22pt" text-align="justify" > text-align-last="justify" text-indent="-14pt"> > internal-destination="_OPENTOPIC_TOC_PROCESSING_d70e1310" > line-height="150%"> >RTI System > Diagram > start-indent="-14pt"> > > ref-id="_OPENTOPIC_TOC_PROCESSING_d70e1310"/> > > > > > > font-weight="normal" last-line-end-indent="-22pt" text-align="justify" > text-align-last="justify" text-indent="-14pt"> > internal-destination="_OPENTOPIC_TOC_PROCESSING_d70e1334" > line-height="150%"> > System > Components > start-indent="-14pt"> > > ref-id="_OPENTOPIC_TOC_PROCESSING_d70e1334"/> > > > > > > > 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 > >
