Skip to main content
J
jroberts-21-Visitor
1-Visitor
November 16, 2016
Question

APP-E ArborText Print Publisher - Enterprise

  • November 16, 2016
  • 2 replies
  • 2983 views

Having trouble with .html files on www displaying the same in all browsers whereby our text has leading non-breaking spaces for indention and lines are justified within a table. I recall ibm mainframe we could tap into a sysprint product whereby we intercept a document sent to the printer and we ran a conversion to handle bolding (repeated text on a new line), underscoring (underscore character on a new line), and striken text (dash on a new line). Since 3b2's .html output option doesn't match the .pdf, is there any mechanism within 3b2's or .pdf to capture and save an exact formatted-output to a file and then we can further interrogate that file to use <pre> tags or the like?

    2 replies

    G
    GarethOakes16-Pearl
    16-Pearl
    November 17, 2016

    Let me get this right, you want to print to HTML and have it look exactly like the PDF? Or you're just saying that the built-in HTML print driver isn't doing a very good job for your pages?

    Latest versions of APP have an XML print driver and JavaScript print driver for which you could then implement your own HTML output transformation. Thinking laterally, an alternative would be to print to PDF then run a PDF-to-HTML tool such as IDR.

    J
    jroberts-21-VisitorAuthor
    1-Visitor
    November 17, 2016

    we utilize 3b2 to generate .pdf's for our website and are very satisfied. Additionally, we use 3b2's .xml output with embedded processing instructions that control page and line breaks as input into our custom xslt transformation process for displaying .html files on the website (this method was necessary since 3b2's .html output has never matched the .pdf output).

    Ideally, we would like to print .html from 3b2 and have it exactly match its .pdf output with hope that every web browser would render the .html the same. Discovering that our custom html transformation was originally designed to render correctly in IE, but now finding other web browsers are not honoring indention/justification (use of non-breaking spaces).

    Using Adobe Acrobat XI 'File/Save as Other/html web page' ignores our page and line numbering along with other subtle differences like indents/fonts - so this is not reliable for our shop.

    Thanks for tips on APP xml print driver and JavaScript - will give them a look.

    G
    GarethOakes16-Pearl
    16-Pearl
    November 17, 2016

    I'm still not sure exactly what you're trying to achieve, but if it is simply correcting the display of preformatted text runs then the HTML <pre> tag is what you're looking for.

    C
    ChrisWestern12-Amethyst
    12-Amethyst
    November 17, 2016

    You can also augment the HTML driver output with generated content or tags using <?passthru> and conditional functions using it (or FOM equivalent depending on your version).

    Bespoke/custom html outputs are cirtainly possible with the XML or JS print drivers as Garath mentioned but are not simple 'out of the box' solutions.

    On a similar track to the PDF to HTML option, Acrobat version 10, PDF to DOCX / HTML options are much better than older versions.

    Regards
    Chris

    J
    jroberts-21-VisitorAuthor
    1-Visitor
    November 17, 2016

    Thanks Chris - with differences in various web browsers displaying our .html files we are investigating alternatives - will see what PDF to html offers us.

    I had hoped that we could tap into 3b2's formatted output prior to saving as .pdf, and simply slap a <pre> tag around it.

    C
    ChrisWestern12-Amethyst
    12-Amethyst
    November 17, 2016

    APP-Enterprise is just running a formatting & print process like any other template under the hood so no reason why you cant add a post HTML print prosess (perl/Javascript) to patch the file as you need (as long as your acs.ini allows time in its timeout settings). Or use <?passthru> in the right place on the first pass could augment these tags potentially which works with the HTML and XML print drivers. 

    From you comments above however i am assuming your not already using the xml print driver but instead saving out your own source XML datastream which has been augmented with the PI's by 3b2? In which case would this not then be some extension to the augmentation process thats already running before the XML is saved out and/or to the XSLT transform?

    Terms & ConditionsCookie settingsAccessibility statement