Hi Hussein, Yay, for including the step number formatting in a future release. Thank you! My ultimate goal is to be able to convert dita files directly to PDF. However, I've got some people here in my organization who are pretty particular about certain things, like how text lands on a page and where next pages should start (i.e., the pagination). While I can control some of it with keep-with-next options, I can't control all of it because it is subjective based on where reviewers want pages to break. It's very 20-year-ago thinking, but something I still have to accommodate. So, for now, I can paginate the .docx file and then convert to PDF (until I convince these people to disregard such things). Also, and maybe this is a request for another parameter ... I have to put the publication date in mm/dd/yyyy format underneath the page number, which is centered in the footer of all pages. And, of course, it is formatted differently than the page number. So I currently can just add that to my footers in Word before converting to PDF. I'm trying to wean these people off PDF altogether and get used to online help or html documents, but it will be a while before I convince them of that. LOL! Thank you, Julie
>>> Hussein Shafie <[email protected]> 1/17/2012 8:18 AM >>> On 01/17/2012 04:46 PM, Julie McHam wrote: > I can wait three months or more for the next release. :) > I appreciate very much all your helpful responses. I have modified our > XSLT stylesheets to the extent that I just have a little work to do to > modify the headers/footers in the resulting docx files and I can > probably write a macro to make our bullets match our standards. > There is one more thing that I don't think I mentioned. Similar to > bullets being a different font and color than the text, our standard calls > for the numbers in steps being bold and blue, with no period following. > It would look something like this: > > *1 *Text of a <cmd> sentence. > *a* Text of a substep. > > I don't know if you have any plans for future releases to parameterize > this type of formatting or not. While at it, we'll also allow to parameterize this kind of numbers in the next release. > Whether you do or not, I can fix in the docx > file before creating a pdf from the docx file. You should really try to create the PDF directly out of your DITA map. Simply select "ditaToPDF" in XSL Utility. No need to generate an intermediate .docx for that. Note that all your customizations also apply *unchanged* to ditaToPDF. That is, if, in XSL Utility, you have edited ditaToDocx to specify some parameters and also a custom fo.xsl stylesheet, then you may want to do exactly the same with ditaToPDF. Note that when you generate PDF, you may need to also parameterize FOP like you did it for XFC. See the "Process" tab in http://www.xmlmind.com/foconverter/_distrib/doc/help/com.xmlmind.xslutil.ConversionEditor.html To my knowlegde, the only real difference lies in the method used to map sans-serif to Georgia and serif to Calibri. FOP does not support XFC's "genericFontFamilies" parameter. Instead, FOP's font map is specified by clicking the "Preferences" button found at the bottom/left of the main window and then selecting "XSL-FO Processor|FOP" section. See attached screenshot See also http://www.xmlmind.com/foconverter/_distrib/doc/help/com.xmlmind.guiutil.PreferencesEditorDialog.html#fop_preferences > Ditac/XML Utility has allowed me to get everything else formatting > fairly close to our standards, so I'm a happy camper so far. > I'm hoping to be able to now "sell" the dita concept to the > powers that be in my organization.
-- XMLmind DITA Converter Support List [email protected] http://www.xmlmind.com/mailman/listinfo/ditac-support
