Wrapping Code in PDF Output

This forum is for all Flare issues related to PDF, eBook, Microsoft Word, Adobe FrameMaker, XPS, and XHTML book targets.

Wrapping Code in PDF Output

Postby doloremipsum on Tue Oct 22, 2019 4:12 pm

My problem: long lines of text in <pre> tags extend off the edge of the page in pdf.

I know that this has been discussed before (in particular here: https://forums.madcapsoftware.com/viewtopic.php?f=6&t=8630) but I haven't found a solution anywhere for PDF output in particular.

A few notes:
  • My experimentation shows that the lines of text will happily extend outside of the <pre> and <body> tags no matter how I try to control them. Really long lines may break eventually, but generally only if they have spaces in them, and often after they have extended off the page.
  • PDF output happily ignores a lot of the standard tools for fixing line break issues in CSS: overflow: auto; white-space: pre-wrap; word-wrap: break-word; overflow-wrap: break-word; word-break: break-word.
  • Madcap Hyphenation rules are not particularly useful because I don't want hyphens in the code. Spaces would be fine, actually.
  • The only thing I've had any luck with is controlling the width of the pre block. If I set a fixed width, the text will actually break to the next line when it gets to the maximum width.
  • However - here's the weird thing. The pre tag seems to start calculating its width starting after any tab characters for the purposes of line length. I would need to set the maximum width small enough that code on e.g. the fourth level of tabs does not extend off the page, but that leads to unnecessary line breaks on the 1st-3rd levels.
  • This weird behaviour applies when tabs are used to produce the white space, but it seems to act as expected (honouring the actual width of the block) when spaces are used.

Possible Solution: Use different style classes with different width definitions for each level of code. A pain because of how much code I have imported from another system, but not inherently impossible. It's really the only reasonable solution I can think of.

But before I implement that: has anyone else come up with a solution to this in the decade since the last forum discussion about it?
neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit - sed saepe cum dolor apud multos callidos mutuetur, reduci potest.
doloremipsum
Propeller Head
 
Posts: 72
Joined: Mon Aug 26, 2019 2:11 pm

Re: Wrapping Code in PDF Output

Postby robdocsmith on Tue Oct 22, 2019 5:45 pm

Sounds like it's a bug that MadCap doesn't recognise tabs as part of the HTML and as you say, ignores them in calculations of the width of the column. It doesn't know how wide to allow for a tab. Which is a shame as there is a default value (a whopping 8 chars width) as well as a mechanism in CSS for specifying the width of a tab - tab-size. This is also ignored, meaning you can't set it to a more sensible and normal 2, 3 or 4 space width.

* edit - now that I think about it, it correctly calculates the width, but instead of using 8 chars for a standard tab, it only recognises each tab as a single char (the tab char unicode U+0009), hence the container overflow on lines with multiple tabs. Still a bug though. I'd expect Madcap to substitute in the tab-size property (or 8 if not present) when calculating the width of a line.

Having said that, I don't know what to suggest. I'd probably pre-process the code imports and find/replace tabs with ".." - your preferred number of spaces. Then your PRE will fit in the container frame and wrap accordingly. Cleaner to me than having multiple styles depending on number of tabs. But then you'd have to remember to pre-process each time there's a code update.



Cheers,
Rob
robdocsmith
Propeller Head
 
Posts: 44
Joined: Thu May 24, 2018 3:11 pm

Re: Wrapping Code in PDF Output

Postby doloremipsum on Tue Oct 22, 2019 6:33 pm

Oh, that is very clever, I reckon I can work with that. This code isn't actually being updated regularly from a live source (I just had to import it from Author-It). So if I can work out how to run a find/replace on a tab, I should be able to replace each tab in the document with 2-3 space characters.

It might need to be done outside Flare, however - the Flare Find window reads all whitespace as the same character. I'll update when I come up with an answer.

I'll make that a bug report with Madcap as well.
neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit - sed saepe cum dolor apud multos callidos mutuetur, reduci potest.
doloremipsum
Propeller Head
 
Posts: 72
Joined: Mon Aug 26, 2019 2:11 pm

Re: Wrapping Code in PDF Output

Postby doloremipsum on Tue Oct 22, 2019 7:52 pm

Easy. I used the FAR: Find and Replace tool to replace every tab (regex \t) in the relevant folder with four spaces. The line breaks aren't perfect (I wish I could tell Flare that it could wrap at particular characters - e.g before < and after >), but they're definitely good enough.

Submitted that bug report. Thank you robdocsmith, another success for the forums.
neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit - sed saepe cum dolor apud multos callidos mutuetur, reduci potest.
doloremipsum
Propeller Head
 
Posts: 72
Joined: Mon Aug 26, 2019 2:11 pm

Re: Wrapping Code in PDF Output

Postby Psider on Tue Oct 22, 2019 8:07 pm

From memory, part of HTML is that all white space is treated as a single space unless escaped (using entity codes). So that is why the tab counts as a single space. (Possibly there should be some sort of switch for either text somehow marked as code, or when generating to Word or PDF. )
Psider
Propellus Maximus
 
Posts: 615
Joined: Wed Jul 06, 2011 1:32 am

Re: Wrapping Code in PDF Output

Postby robdocsmith on Tue Oct 22, 2019 10:32 pm

doloremipsum wrote:Easy. I used the FAR: Find and Replace tool to replace every tab (regex \t) in the relevant folder with four spaces. The line breaks aren't perfect (I wish I could tell Flare that it could wrap at particular characters - e.g before < and after >), but they're definitely good enough.

Submitted that bug report. Thank you robdocsmith, another success for the forums.


No worries. And yes, no handy regex '\t' search inside Flare. Tabs are invisible to Flare's search and replace. This kind of makes sense because Flare itself will indent HTML files with tabs.

I remember hand coding in appropriate line continuation marks for long code lines before to make them more readable (depending on language), or just hand inserting the line breaks where I want them. I do my text work in a text editor like Sublime or Notepad++ so I've better control over what I'm seeing before pasting back into Flare.

Cheers,
Rob
robdocsmith
Propeller Head
 
Posts: 44
Joined: Thu May 24, 2018 3:11 pm

Re: Wrapping Code in PDF Output

Postby oceanclub on Wed Feb 12, 2020 4:27 am

Thanks for the summary above. It is very frustrating that <pre> in PDF files seems to almost but not quite work. Wrapping happens most of the time but random lines will extend a character or two beyond the border in places. Manual tweaking is not really an option since we auto-import/convert a lot of our documentation now.

Paul
User avatar
oceanclub
Sr. Propeller Head
 
Posts: 197
Joined: Thu Oct 10, 2013 4:45 am
Location: Dublin


Return to Printed Documentation Targets

Who is online

Users browsing this forum: No registered users and 4 guests

cron