DITA and XMetaL Discussion

XMetaL Community Forum DITA and XMetaL Discussion pretty printing often causes problems with eclipse/webhelp output formats

  • njmyers13

    pretty printing often causes problems with eclipse/webhelp output formats

    Participants 3
    Replies 4
    Last Activity 9 years, 2 months ago

    Hi Derek,
    I had pretty printing turned off in XMetal 6 because the line breaks and spacing it puts between element tags caused weird tabbing and line feeds in webhelp and Eclipse outputs. When I upgraded to XMetaL 8, it changed all of my plain text back to pretty printing and the same thing is happening. So… I figured out — with help from Yas — how to set the necessary permissions on the xmetal software files so I could run the “turn off pretty printing macro”.
    Rather than go through every file by hand and remove all of the carriage returns and spacing, Yas thought that this is probably a common problem and you might have a script that does it automatically (without removing the formatting that is desired in codeblock, etc…). Do you have such a script?
    I'm on Win 7, 64bit.
    thanks,
    Nicole

    Reply

    Derek Read

    Reply to: pretty printing often causes problems with eclipse/webhelp output formats

    We do not have anything. There has been the odd time that this has come up, but in those cases it was primarily due to their integrations with differencing engines that are not XML or DITA savyy (ie: they don't understand the difference between significant and insignificant whitespace) not DITA output. Perhaps we could look into creating something.

    We would be interested in hearing how this is causing issues in your output. I can't think of a reason why insignifigant white-space could cause issues, especially in HTML-based outputs. Perhaps Yas could contact us through XMetaL Support so we could discuss. Some good examples would be useful.

    However, if there are limitations in particular outputs they should probably be filed as defects with the DITA OT project.

    Reply

    njmyers13

    Reply to: pretty printing often causes problems with eclipse/webhelp output formats

    I'll keep an eye out for some examples and send them to you. The line break and indentation problems usually appear after a closing element, such as . I actually found an example for you. Please see the attachment. Hopefully it will help. I can send you the actual source if you'd like.
    thanks,
    Nicole

    Reply

    Derek Read

    Reply to: pretty printing often causes problems with eclipse/webhelp output formats

    The setting in our pretty printing settings that is introducing white-space is that the max line length (which defaults to 80) is being reached in some cases, and XMetaL chooses (as designed) to wrap those lines at the first possible white-space, which may happen to be inside a element (or any other element not specifically designated as “do not pretty print”) if there is enough content before that element to put the line over the 80 character limit.

    It still seems odd to me that this causes issues with XHTML-based outputs, and that part of your issue I cannot reproduce yet. I'm pretty sure I've tested all the possibilities by having pretty printing turned on and using this XML that tries to mimic your content and test various possibilities with and withour and with a that has a carriage return within it as in one of yours:

    [code]
     task title
     short description
     

     


     this is step 1
     

     

    • name1
       is a descriptive name for the attribute.
    • name2
       is a descriptive name for the attribute.
    • name3
       is a descriptive name for the attribute.
    • name4
      varname
      is a descriptive name for the attribute.
    • name5
       is a descriptive name for the attribute.

     


     
    [/code]

    When I generate HTML outputs from that file (it is identical for all HTML outputs, including Webhelp) they don't seem to appear like your screenshot, and the HTML source actually looks like the following. All spaces are “regular” spaces and appear here as in the actual output, so the DITA OT is doing some form of normalization, at least in my case:

    [code]    

    this is step 1
           
         

    • name1 is a descriptive name for the attribute.
    • name2 is a descriptive name for the attribute.
    • name3 is a descriptive name for the attribute.
    • name4 varname is a descriptive name for the attribute.
    • name5 is a descriptive name for the attribute.

    [/code]

    I suspect at this point that somehow some changes you have made to the DITA OT are introducing the behaviour you are seeing, or my test case is not the same as what your actual content looks like, or there is some other trigger. I'm pretty sure it must be the first case as I clearly see pretty printing in my input file (as above) and that white-space is collapses by the DITA OT in my output (as above).

    When loaded into a browser (it doesn't matter which because the markup is so simple) I see what I've attached as test_screenshot.jpg

    Reply

    Derek Read

    Reply to: pretty printing often causes problems with eclipse/webhelp output formats

    My mistake with the XHTML output source. I mixed up my virtual machines and tested with 7.0 previously.

    However, with 8.0 (which uses the DITA OT 1.7) and the identical XML input I quoted before, I get slightly different output in the HTML, but the browser handles it just fine as expected, and renders the output exactly as with the previous screenshot. The HTML source looks like this but the browser (tested with IE and FF) renders it identically (as it should as the spaces in question should be collapsed as per the HTML rules):

    [code]

     this is step 1
     

     

    • name1
       is a descriptive name for the attribute.
    • name2
       is a descriptive name for the attribute.
    • name3
       is a descriptive name for the attribute.
    • name4
      varname
      is a descriptive name for the attribute.
    • name5
       is a descriptive name for the attribute.

     

     [/code]

    Reply

  • You must be logged in to reply to this topic.

Lost Your Password?

Products
Downloads
Support