Incorrect letter spacing, kerning in PDFs

[Gary Niemen]

I have six PDFs in my documentation set. All are set up the same way and use the same stylesheet.
The day before yesterday, two of the PDFs started building with incorrect letter spacing, kerning - that is, headings, headers, footers, text, and so on - all of a sudden, contained extra spacing in the middle of words.
I searched a lot on Google and on this Forum - and, finally, homed in on the solution.
Solution: Add the following to the body tag in the stylesheet.
letter-spacing: -1pt;
It worked. The two offending PDFs now look like they used to.
I am just posting this to help others who might come across this rather bizarre issue.

[Nita Beck]

Gary, it would help the community to know what version of Flare you are using.

[Gary Niemen]

Yes, sorry - thought of that on my cycle home
Flare 12

[Gary Niemen]

So now my PDFs look fine, but...
My source looks awful.
Perhaps I need to put the letter spacing setting in the print medium tag.

[Gary Niemen]

Slotted letter-spacing into @media print, took it out of the body element, and view my source as Medium (non-print).
So now the source looks fine and the PDF looks fine. What a workaround

@media print
{
p
{
letter-spacing: -1pt;
}
}

[Gary Niemen]

This issue is still not really resolved.
Does anybody have any clues as to what might be going on?
The letter-spacing -1pt works to some extent, but the kerning is still not as it should be - and as it used to be.
All other documents in my document set - using the same stylesheet - are fine.
Would be so grateful for any hints...

[Sylverre]

No help here, just a fellow sufferer!

I have Flare v. 10, 11, and 12 on one Win10 machine for testing purposes. Switching from 10 to 11 (same project) reduces the size of a single PDF with no loss of readability (260 to 240 pp). Built the project in 11 to make sure everything still worked, then in 12--and the result was up to 280 pages and completely unreadable due to kerning. Tried the -1 fix mentioned above, but while the result was a little less ugly it still wasn't readable (and still larger than the same doc in the other versions: 271 pp.). And v12 with the code-fix ate my header font.

Can't leave that new code in the stylesheet or it messes with the output in v11. Which is what I'm using while I try to figure out how to make v12 work. Anyone submitted a bug yet?

Sylverre
techical writer, RF Code

[Gary Niemen]

A fellow sufferer. I was beginning to think I was going mad.
No, I haven't submitted a bug - but I am willing to do so.
How do I do that?

[ChoccieMuffin]

Click the link in my signature.

[NorthEast]

In Flare, Help > Report a bug.

[Gary Niemen]

I have now reported the bug.

[Gary Niemen]

Latest: I had to go back to Flare 11 to get decent PDFs out.
When using Flare 12, some of the PDFs were okay, some not.
I am using Windows 10 by the way - wonder if that is a factor.

[doc_guy]

Could be a font magnification issue on your PC.

Here is a topic in the help that discusses this issue: http://help.madcapsoftware.com/flare12/ ... =PDF%20100

Even though it says "Windows 7," people using Windows 8 and Windows 10 have reported that resetting the magnification as specified in the topic, has helped their PDF outputs.

[Gary Niemen]

Yeh that seems to be the issue - but I have said that before
On Windows 10, I decreased the font magnification to 100% and the PDFs generated fine.
The trouble is then, my Windows Desktop and everything on it is now too small for my "old" eyes.
Anyway, to check, I put the font magnification back up to 125% and the kerning problem is back.
Flare 11 works fine with a font magnification of 125%.
So,
Flare 12 and Windows 10 with the default font magnification 125% = kerning problem
Flare 11 and Windows 10 with the default font magnification 125% = correct PDFs
Flare 12 and Windows 10 with the font magnification set to 100% = correct PDFs (but Windows Desktop too small)

[Sylverre]

Tried resetting the display to 100% (Win10, Flare12) before building a PDF as described in this thread, and, yes, that works. I'm actually sad to have to report that, as it seems to mean there's no way I'm ever going to be able to use Flare12 for automating publication updates. Probably not the only customer in a similar situation:

1. Flare is installed to my machine rather than a network; 2) I keep my systems set to 150% to preserve such of my vision as remains; 3) at least some of the documentation is in PDF.

...back to 11.

[ChoccieMuffin]

Tried resetting the display to 100% (Win10, Flare12) before building a PDF as described in this thread, and, yes, that works. I'm actually sad to have to report that, as it seems to mean there's no way I'm ever going to be able to use Flare12 for automating publication updates. Probably not the only customer in a similar situation:

1. Flare is installed to my machine rather than a network; 2) I keep my systems set to 150% to preserve such of my vision as remains; 3) at least some of the documentation is in PDF.

...back to 11.

I found the output was sometimes a bit dodgy even in Flare 11 if the display wasn't set correctly, so don't rely on Flare 11 for what you want to do. Depending on how often you generate outputs, would it be an acceptable workaround to change your display settings each time? Or is that just a stupid suggestion? (It may well be, in which case, please accept my apologies.)

[Sylverre]

I found the output was sometimes a bit dodgy even in Flare 11 if the display wasn't set correctly, so don't rely on Flare 11 for what you want to do. Depending on how often you generate outputs, would it be an acceptable workaround to change your display settings each time? Or is that just a stupid suggestion? (It may well be, in which case, please accept my apologies.)

Certainly not stupid, but no, not acceptable nor practical for me; I'm just at the point now where scheduling batch publication of online and PDF outputs is an option, but I'd still have to _manually_ change the settings and log out before the scheduled PDFs would render correctly. Not worth the risk of my forgetting (or Win10 deciding to update something and returning to my established preferences).

[ChoccieMuffin]

We have a separate build machine that only runs Flare using madbuild, and our build are scheduled on there rather on our local machines. Therefore we don't have to worry if our own locally generated PDFs aren't quite how they should be, and we don't have the worry that any other work we are in the middle of might be slowing down our build, or updates happening in the middle of a build. Is that sort of setup a possibility for you? (Just clutching at straws for you, really, there may be no other solution.)

[Sylverre]

We have a separate build machine that only runs Flare using madbuild, and our build are scheduled on there rather on our local machines. Therefore we don't have to worry if our own locally generated PDFs aren't quite how they should be, and we don't have the worry that any other work we are in the middle of might be slowing down our build, or updates happening in the middle of a build. Is that sort of setup a possibility for you? (Just clutching at straws for you, really, there may be no other solution.)

Small company, one technical writer. Not really an option, but thanks.

[Gary Niemen]

I have resorted to building with Flare 11. That seems to be the only sensible, working option at the moment. I have reported the bug to MadCap, and also told them that changing the default font magnification is not a viable workaround. No reply yet.

[Gary Niemen]

Interesting. Now I find that the Ctrl F Find does not work for PDFs affected by this bug. This is because although the issue is to do with kerning - what actually happens is that the words end up with spaces inserted in between letters. So when searching for a word, that word is never found - because the word only exists with spaces in between some of the letters. So there is no match. MadCap, please fix this bug.

[cherwoo]

It seems this is still an issue in Flare 12 on WIndows 10.
So, if you're having this issue, check your Windows magnification setting. Mine was set to 150% by default. Once I changed it to 100%, the print to PDF font issue disappeared.
Strange that it affects the print output in Flare.
Of course, I can't read my screen now, but I can produce docs, so ...!!!

[Amanda_Wood]

I was so excited when I found this post.... Flare2017r2 , windows 10, weird spacing in the PDFs. I have tried a whole bunch of things to no avail. Finally found this, but did not change the right setting when I read the information so for clarity.

Emailed MadCap support and they said "Windows Display Settings and verify that the scaling / DPI is set to 100%."

I had previously gone in Flare to Target >PDF Options> magnification settings in error, thinking that was what was meant. Then I tried the real solution but important point, you need to either log out or reboot to make those settings work. I include a screen shot for others who get confused in the future before this is fixed.

The issue has been reported to MadCap. It is Issue Report 123341.

I spent half a day thinking it was something I had done, waste of time. So if you go through the same I suggest you also submit a bug report. The more people who do that the better.