Forum Replies Created

  • Fa

    Reply To: Plugin and RenderX: how to make them communicate?

    Participants 0
    Replies 13
    Last Activity 5 years, 4 months ago

    Thank you Derek!

    As I suspected, my plugin is not using XEP, but FOP. Even with the RenderX folder renamed it produces the same layout.

    This might explain why the xmfo plugin recognizes “Sans”, and my custom plugin requires “sans-serif”. My custom plugin only uses sans-serif, serif and monospaced, I have no reference to any font name, so the “fallback” fonts are probably those you cited, referenced in the pdf2 plugin.

    I have tried changing throughout my plugin all fop references to xep references, but that breaks the output.

    The files I have modified are:

    xsl/fo/topic2fo_shell_fop.xsl renamed to xsl/fo/topic2fo_shell_xep.xsl (I have also modified the integrator.xml file reference to the file to reflect this name change) and modified as follows:

    [code]
     
     
     
     
     
     
     
    [/code]

    Changed to

    [code]
     
     
     
     
    [/code]

    In cfg/fo/attrs/basic-settings.xsl, I changed the line
    [code]
     
    [/code]

    to

    [code]
     
    [/code]

    Are there some files at a higher level (e.g. DITA_OT level) that would require editing for this to work, or is this the wrong approach?

    Also, should I define another plugin under “require” in plugin.xml? Currently it is set to
    [code] 
    [/code]

    Thank you!

    Reply

    Fa

    Reply To: Plugin and RenderX: how to make them communicate?

    Participants 0
    Replies 13
    Last Activity 5 years, 4 months ago

    Thank you for your answer, Derek.

    I thought I had managed to get it to work, but I just tested and it's not working as I thought it should.

    In my commons-attrs.xsl file, I have my base font set as:

    [code]
    sans-serif
     
    [/code]

    Then I have applied that base font throughout the file using an __fo__root attribute set.

    [code][/code]

    Note that I had to use “sans-serif”, while I thought that “Sans” would have been the obvious choice, but it did not work, although they are listed as aliases in my font-mappings.xml (and “Sans” works for my xmfo plugin!!!)

    [code]   
          Sans
       
    [/code]

    Using “Sans” reverts to using a serif font (I'm not sure which one and I have no idea where it gets it from).

    Anyway, font-mappings.xml defines Sans (so sans-serif, too, if aliases work) as using Arial as default

    [code]   
                  Arial
         
    ….
             
    [/code]

    From what I understand (and I've been able to test that using the xmfo plugin XMetal Enhanced PDF via RenderX XEP), Arial here is only a “face”, you then point to the font files in the xep.xml file. In xep, I have Arial defined as follows:

    [code]     
           
             
           

           
             
           

           
             
           

           
             
           

         

    [/code]

    and I replaced the first font file with a totally different font, which makes the change obvious in the output:

          [code]
           
             
           

           
             
           

           
             
           

           
             
           

         
    [/code]

    This works [u]with the xmfo plugin[/u], i.e. I see the Bauhaus font used wherever the regular sans (or sans-serif) font should be used when generating, but I see no change in my own plugin.

    Another very odd thing is that, as stated above, in the xmfo plugin, I can use “Sans” and not “sans-serif”, and it is recognized, but as I said, my own plugin only recognizes “sans-serif”.

    So to summarize, my plugin applies the correct font when I refer to “sans-serif”, but when I use “Sans” (which works for xmfo), it just falls back to to a serif font, and I don't know what that fall back mechanism is, neither where the said serif font is defined. And this is very annoying, because before I figure that out for default (US English) documents, I won't be able to get my other languages to work with different fonts (Chinese at the moment only shows hashtags ## instead of the Chinese glyphs, although Sans and Serif are both mapped in Font Mappings and xep to Chinese fonts).

    I'm kind of short of ideas about what to do or try next, so I'd really appreciate a small nudge in the right direction. Ideas anyone?

    And by the way, is there a way to know for sure that my plugin uses renderX? Where is the pdf renderer defined?

    Thanks!
    Fa

    Reply

    Fa

    Reply To: Customized conditional texts not available for build

    Participants 0
    Replies 13
    Last Activity 5 years, 7 months ago

    Thank you, Derek.

    It worked like a charm!

    Best regards,
    Fa

    Reply

    Fa

    Reply To: Unable to create PDF file due to foreign element

    Participants 0
    Replies 13
    Last Activity 5 years, 7 months ago

    Hi Derek (and anyone else interested)!

    Following up on this topic (sorry about the long delay!).

    After discussion with my colleagues why they had ended up creating their own elements, it turned out that the main (and probably only) reason why they did that is that the program they develop uses context sensitivity.

    The help file they create is a simple “single html file”.

    Since they are writing their code for the different modules before the corresponding help topics even exist, they already create a context sensitive link within the software pointing to an element that does not yet exist (in a file that does not yet exist either).

    At first, they tried to use the topic id attribute value as a unique identifier, but it failed because of the way the conversion is done. When DITA-OT processes the xml topics, it collects all the links and targets (in this case the topic id's), and it renames all targets in the html to “#unique_01”, “#unique_02”, etc.

    I guess the reason behind the behaviour is that since it creates a single html out of lots of small DITA files, it wants to make sure there are no duplicate anchors, and therefore, instead of having a mechanism that checks for duplicate, it just coldly replaces all names for anchors created from elements with new names that it knows are unique.

    The drawback in this case is that there is therefore no way of knowing what to link to before the html has been built, and even then it would require a lot of manual work. That's how they came up with the idea of creating the help_anchor elements that they then process to become an html anchor ().

    So my question now is: is there
    a) a way to force XMetaL (DITA-OT) to keep the elements' IDs intact and transfer them to the href attribute value for anchors (
    ) in the html instead of replacing them by the #unique_nn value
    or
    b) an existing, valid DITA element that could be use for this purpose?

    Thank you!

    Reply

    Fa

    Reply To: Issue when trying to create Chinese output

    Participants 0
    Replies 13
    Last Activity 5 years, 10 months ago

    Hello Derek,

    Thank you for your answer. As I said in my original post I tried “Book via RenderX” out of curiosity, but again out of curiosity, I tested editing the pdf2 font mapping to correspond to what I have in the xep.xml file, and I got a much better result: I got most of the Chinese text, except for a few glyphs that did not display (I get the “missing character” symbol aka square), which I could then fix by extending the character range in i18N for zh_CN.

    Regarding the “XMetaL enhanced pdf via RenderX XEP”, my previous version of XMetaL was 6.0. I don't know what version of DITA_OT it used, but yes, there have been a lot of changes at least in how the folders and files are structured. What I did to get my customizations back was to use a diff tool to see everything I had done to the DITA_OT provided with XMetaL 6.0 by comparing the original DITA_OT folder with the one I had customized (and also the xep.xml file). I thought I had successfully transferred all my modifications to the DITA_OT2.2pluginscom.xmetal.xmfo folder, where I believe the changes for pdf via renderX should be made.

    Most of the changes have been successfully implemented (page size, fonts used, etc.), even Russian works: I get the output with no error. I have not yet tried producing other Asian languages I work with, but that's my next step (Japanese, Thai, Vietnamese). I'll see if these work or if I get the same issue as with Chinese. 

    For most of the files, I have edited them to reflect the changes I had made for XMetaL 6.0, but I might indeed have, for one or two files, just copy/pasted (overwritten?) them instead of editing their equivalent in DITA_OT2.2. I will check, but I don't remember overwriting many files.

    Thanks!

    Fa

    Reply

    Fa

    Reply To: Unable to create PDF file due to foreign element

    Participants 0
    Replies 13
    Last Activity 5 years, 10 months ago

    Thank you very much Dereck for your detailed answers. You raise some very good points in them.

    I have already looked at the possibility to create our own DTD, but as you will have noticed, I have no experience with it at all and very limited knowledge and understanding of DITA in general. And I don't think the company is willing to purchase custom-made DTDs, so that's kind of out of the question. Also the point you raised of no longer having standard DITA raises a red flag.

    I will try to understand better why they need these and how they are converted.

    Right now your second suggestion really seems the best (where we would use valid DITA elements and modify the xslt to convert those elements to whatever they want in the html output). So thank you again for taking the time of posting a second reply with this suggestion!

    I will follow up on this as soon I get something new to tell.

    Best regards,
    Fa

    Reply

    Fa

    Reply To: XMetaL 11 Unable to resolve paths with file://

    Participants 0
    Replies 13
    Last Activity 5 years, 11 months ago

    I also have a very similar issue (in XMetaL 11 too).

    I have created a small DITA map with a few topics that I keep always in the same location (a drive on our intranet, mapped on my computer). This DITA map (let's call it ComRef, for common references) will then be included in all my manuals (indented or embedded or however you want to call it in my manual DITA maps). The idea, since this is general information, is that if there is something to be updated, we correct it once here, and then any manual we generate subsequently will get the updated info.

    Then I have created a template for my manuals. This template is a DITA map with several topics, and in it I have embedded the ConRef map (well, a link to it). The idea is that I can take that template and copy it anywhere on my local machine or network and it would work. This means I should be working with absolute paths, where by default XMetaL creates a relative path to the ConRef map (is there any way to change that?).

    Unfortunately this ConRef map is not rendered in the pdf output. The only thing that works is if the embedded ConRef map is in the same folder or a subfolder of where my template map is, which defeats the purpose.

    What I have tried unsuccessfully:

    – Change the ConRef map path from relative to absolute.
    – Change the reference to the map to topicref instead of mapref (XMetaL 6.0 created a topicref for embedded maps, so I gave it a shot)

    I have tested this with my old XMetaL 6.0, and there there was no issue. The output pdf is created without problem and has the embedded ConRef map material in it.

    I now finally seem to have solved it (partially). The trick was to work my way through the path of both maps and renaming everything so as not to have any space (in the folder names but also in the map names). At least this worked with a relative path, I still have to test with an absolute path. But this is very unpractical! I have thousands of folders, so I cannot obviously be expected to rename them all.

    Anyway, hope this will help you and maybe put you on the right track to solve your own issue…

    Regards

    Reply

    Fa

    Reply To: ConditionalTextExporter error

    Participants 0
    Replies 13
    Last Activity 10 years ago

    Hi!

    Thanks for posting your workaround, I just ran into the same issue. I'll try to rename the map.

    Cheers!

    Reply

    Fa

    Reply To: DITA: Configuring XMetaL Author Enterprise to Generate Localized CHM Files

    Participants 0
    Replies 13
    Last Activity 11 years, 2 months ago

    Hi Derek,

    Would you have an updated guide for Windows7? I find myself having TOC and Index display issues in non-English languages.

    Best regards,

    Fabien

    Reply

    Fa

    Reply To: Chinese "Contents" and "Index" titles do not display in pdf

    Participants 0
    Replies 13
    Last Activity 12 years, 10 months ago

    Thanks Paul, but after investigating a little further, I have found where the error originates: the TOC header font family had been changed to Arial in the toc-attr.xsl file. I now got the TOC and Index headings to display as other titles, but I'm still struggling with the Index entry in the TOC that does not appear. It's probably still a font issue, but I don't know where to fix it.

    I have also noticed that in the pdf document bookmarks, titles that are on the same level are not displayed with the same font. Has anyone has encountered a similar issue before?

    Regards,

    Fabien

    Reply

    Fa

    Reply To: Chinese "Contents" and "Index" titles do not display in pdf

    Participants 0
    Replies 13
    Last Activity 12 years, 10 months ago

    Thanks Paul,

    It could very well be. But since both these items are hierarchically on the same level as the other main parts in the manual (at least Index appears to be so in the table of content of manuals in other languages), I assumed it would use the same font (i.e. the font assigned to topic.title in the custom.xls file).

    Are the attributes for Content and Index set somewhere else?

    Fabien

    Reply

    Fa

    Reply To: Chinese titles and punctuation not displaying in pdf (DITA).

    Participants 0
    Replies 13
    Last Activity 13 years, 1 month ago

    Thank you very much Derek,

    I now got all the missing characters to display. At the root of the problem was that, although those marks (range U+FF01 – U+FFE5) were present in the font file (displayed in windows character map), they were left out of the range defined by default for zh_CN.xml file under C:Documents and SettingsMYUSERNAMEApplication DataSoftQuadXMetaL SharedDITA_OTdemoxmfocfgfoi18n.

    For information, I use the Simsun font for body text and Simhei for titles.

    What I did was just to include them, so I replaced the following

                     
        Ā
       
     

    with this

                     
        Ā
       
     

    and that solved the issue.

    Again, thank you very much for your help Derek!

    Merry Christmas to all of you!

    Fabien

    Reply

    Fa

    Reply To: Chinese titles and punctuation not displaying in pdf (DITA).

    Participants 0
    Replies 13
    Last Activity 13 years, 1 month ago

    Hi all!

    So it seems I got the title issue solved. It was due to a wrong mapping of font families, but unfortunately, the punctuation issue remains unsolved. Any tip would be welcome!

    Thank you

    Fabien

    Reply

    Fa

    Reply To: Link to a topic heading?

    Participants 0
    Replies 13
    Last Activity 14 years, 2 months ago

    ghkrause and Su-Laine Yeo, thanks a lot for your answers! They address the first of my issues. I have many more questions, but since I think they are more related to DITA than XMetaL, I'll see if I can find answers from the Yahoogroup dedicated to DITA.

    Cheers,

    Fa

    Reply

Products
Downloads
Support