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: 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?
in hoc foro dolorem ipsum amamus, consectimur, adipisci volumus.
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.
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.
in hoc foro dolorem ipsum amamus, consectimur, adipisci volumus.
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.
in hoc foro dolorem ipsum amamus, consectimur, adipisci volumus.
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. )
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.
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.