Missing hyphen when XML code goes to new line

[Scotty]

Weird behaviour with PDF outputs in Flare 10.

I have a document that includes some XML code (i.e. the reader sees the code in the PDF). The following line of XML is to be shown:

<config-property-value>xbean:broker-config.xml</config-property-value>

In the PDF that is created, the end of the line splits at -value>:

<config-property-value>xbean:broker-config.xml</config-property-
value>

However, when that line is copied from the PDF and pasted elsewhere, the following is output:

<config-property-value>xbean:broker-config.xml</config-propertyvalue>

i.e. the hyphen at the end of the line is missing.

Known bug? Is this a problem with Flare's generation or with the PDF reader or with the PDF format itself?

A related aside, when a line of code splits at a space, copying and pasting that line results in the space being omitted. For example:

<node>Some important stuff and things in here</node>

might split as:

<node>Some important stuff and things
in here</node>

When copy and pasted, it appears as:

<node>Some important stuff and thingsin here</node>

...the space after 'things' is missing.

[kwag_myers]

How are you tagging the code? If you use a pre tag, this should not happen: w3schools.com

As for an explanation, my guess is that Flare is substituting hyphens with HTML code (–) and spaces with  . Since this is syntax, Flare ignores (omits) them when generating a print output. I'm curious to know if you look at a known instance of this in the Text Editor whether these are in the topic file itself?

[Scotty]

I'm using <p> tags.

Hmmmm. I've also tried this with commercial PDFs (not generated in Flare), the problem still exists. Basically, if there's a hyphen at the end of a line, it is removed when copy and pasting. This is when using Adobe Acrobat Reader and FoxIT.

The behavior in SumatraPDF is slightly different - the final hyphen is kept, but so is the line break.

Ideas for strategies to deal with this? The code must be viewable in the PDFs.

[atomdocs]

Does using pre tags help, as kwag_myers suggests?

I expect that with p tags, the PDF software is reading the last hyphen as standard hyphenation, so when the text is copied, it "helpfully" rejoins property and value as it thinks they are one word that has been hyphenated at the line break. I don't expect that you can control that in your end-users PDF environment.

If pre tags don't work, looking at the example you've given, it seems that it would fit on one line if given its own full line to use. Is it possible to reformat your content so that the XML statements always go onto a new line? I appreciate that this might be restrictive, and won't work if you have a statement longer than one line, but I can't think of anything else.

[mattf]

I'm seeing this same behavior in the <pre> tag. I was given some code, one line of which is several monitors'-width long and includes hyphens, periods, and underscores. In the PDF output, this long line is broken at several places at the hyphens or underscores so that it fits on the PDF page. But all of the hyphens and underscores and periods are present. When I copy the code from the PDF output and paste it into Notepad, a few of the hyphens are missing, but not all of them. It seems random. The text still breaks at a hyphen or an underscore, in one case it breaks at a period. But several of the hyphens are gone. This is not acceptable because the whole point of my putting the code in a <pre> tag is so that an end user can copy and paste the code.

In the year+ since the original post above and subsequent responses, has anyone figured out what to do about this? This long line cannot be shortened...it's an authentication code. Granted, this one is a sample, not meant to be used and actually tampered with so that it won't work, but in other cases I need that long line to remain copyable.

What to do? Any ideas welcome...

Thanks,
-Matt

2016-06-20_12-19-52.png

2016-06-20_12-23-27a.png

[Rene Severens]

Hi,

see viewtopic.php?f=6&t=20236

If you are having this same issue, please also report a bug at MadCap Flare. The more people do this, the higher the change they will fix this.

Greetings
Rene Severens

[mattf]

Hi Rene,
Thanks for commenting. I looked at your topic and I see that the white spaces between elements have to be inferred when those elements are dropped to another line, which is a bummer, but it seems like something a user could figure out. White spaces don't seem to be at issue in my scenario. There are a white spaces in front of some of the lines for indenting, and there are one or two after the name of the field, but they are not far enough to the right for the line to break there, so it's not an issue.

My problem is that hyphens that are part of the actual string are being removed, and yet I'm not even sure that it's Flare that is doing the removing, since they appear in the PDF output. It's when I copy that output and paste it elsewhere that the hyphens go missing, so the question I'm wondering is -- has Flare changed the nature of those hyphens, or are they being dropped by the clipboard for reasons unrelated to Flare?

[mattf]

I've had MadCap Support looking at this for a week or so and they've determined that it's a bug. In fact, it's Bug 119499.
If this bug is buggin' you too, please let MadCap know so that fixing this will be prioritized.

Has anyone else noticed that hyphens get added and removed from wrapping code blocks when copying and pasting from the output PDF?
-Matt F.

[ThorbjornN]

I have come across the same problem as the OP. Have added my voice to the fixing of Bug 119499 through the bug reporting system. Every vote counts, right?

/Thorbjorn

[mattf]

Thanks thorbjorn!
(oh, apparently 17 characters is fewer than the minimum for a post here -- so this is me adding characters to my post).

[Scotty]

Interesting to see others running into this issue too. Ass mattf says, it makes copy and pasting example code a minefield.

I'm assuming the issue is something along the lines of Flare using 'end of line hyphenation' -type hyphens rather than basic hyphens? Then again, I had the same issue with non-Flare generated PDFs, so wondering if the PDF standard is also partly bugged, or at least tricky to deal with in this respect.

[PK]

Hi all,

I'm also creating documentation that has a number of long code instances that must be copied and used as is.

Flare appears to be inserting a hyphenated break as follows:

Intended code:

jdbc-driver=oracle:add(driver-name=oracle)

Actual PDF output:

jdbc-driver=oracle:add(driver-name-e=oracle)

Not only is the hyphen inserted but it also duplicates the last character of the preceding word.

This occurs when wrapping the code in <pre> tags.

Is this definitely a bug or has somebody found a workaround?

Thanks!

[mattf]

PK,
Yes, it's a real bug. Madcap has logged it as Bug 119499. But to clarify, my issue (original post) happens when I copy and paste a block of hyphenated <pre> text from the PDF to somewhere else. Your post seemed to indicate that you're seeing this added letter and hyphen in the PDF itself. That would be a different symptom, although it may be caused by the same thing.