I have a chapter heading that is converting to PDF weirdly, but only for one file. The tags used for the headings are identical in both files. The tag used in the generated TOC is identical for both entries.
This is what it looks like in the generated TOC:
This is what it looks like after the PDF output is created.
Why is the word Software so oddly spaced in both entries after conversion to PDF? It's only those two headings that convert so oddly. All the others are spaced correctly.
After a LOT of fussing, including removing the original TOC files and creating new ones, doing a MIF wash, reinstalling Acrobat, and using the Publish pod instead of Save as PDF, I finally got a version that did not have the weird spacing for the word "Software" in the TOC (and only in the TOC, and only that word, even in other titles with multiple words in them).
I used File > Print Book. The oldest way of creating a PDF from FrameMaker there is, and it worked. Rock-solid, reliable Print Book, how I love thee.
Someone remind me what the difference is between the 3 methods of generating a PDF output are, please?
PDFs have evolved over the years, and unlike the CC applications, FrameMaker did not do a good job keeping up until recently.
Using File > Print still produces a PDF that opens in Acrobat, which is the bit I'm interested in.
The only thing I use Acrobat for is creating PDFs for publication or commenting. Occassionally I use it to export graphics, add or remove pages, combine files, or compare files.
Have standards changed enough that I need to be worried about this? I can send the PDF out with the words messed up in the TOC if so, but it irks me no end to do so. It also puzzles me that it's only those two places this happens, and it's the same word it happens to. There's a problem somewhere, but it doesn't appear to be anything I can fix.
For your stated purposes, the Print to PDF should be fine. The PDF/A formats are meant for archiving—reducing risks to the future reproducibility of the content and ensuring that the files will look the same today as in the future. The PDF/X formats are geared to facilitating graphics exchange and contain commerical printing-related requirements.
Good to know.
I'd still like to know why it happened in the first place, though. It's just weird.
Which job option did you select in Publish Settings?
It's essentially the Standard joboptions, with a couple of tweaks on the General and Images settings (see the following screenshots).
We need the images to be as high resolution as possible when zoomed in, so they are no longer compressed or resampled at all after complaints that they were too grainy. We use Source Sans Pro as our font. Since that's activated through Adobe fonts it can't be embedded, so I deselect the Rely on system fonts only option, as I most definitely want the PDF created with the document fonts.
[Other things I did that weren't listed as part of the troubleshooting include replacing the user variable that inserted "Pulse" into the title with plain text, removing the hard space between "Pulse" and "Software", moving the Index marker that had been inserted after the word "Software" to the end of the text paragraph after it, and retyping the phrase "Pulse Software". All to no avail.]
I honestly don't think the settings are the issue. This same document has been created in the past, with the same font and the same settings, with no issues on the TOC.
Those are screenshots from the File > Print workflow, which I though was working for you.
Wasn't the odd spacing on "Software" from using the new engine in the Publish pod?
I normally use the Save as PDF flow. I tried Publish when that didn't work. I thought those settings applied to Save As PDF as well as to the File > Print flow. I used File > Print as a last resort.
These are the settings in the Publish pod. Other than selecting the custom joboptions file, I think they're pretty standard.
[Side note: At Zoom is still not reliable.]
When you activate the Use Acrobat Distiller option, you should get the same result as when you print to PDF.
You said that the text is a variable. Is there any formatting info in the variable? Do you get the same issue, when you copy the paragraph and enter the same text manually? Or just a portion of the text (without the tab and the page number)?
I had such an issue a few years ago, but I cannot remember what the issue was.
I did not activate the Use Adobe Distiller option in the Publish pd, nor did I print to a .ps file when I used File > Print Book.
I think you may have missed some of the troubleshooting I did, so here it is, all in one spot:
There were no character tags applied to the two headings in the source file, nor did I add any to those lines in the TOC after the TOC file was generated. There is no character tag applied in the definition of the user variable, not even <Default font>.
And, I might add, the last time I worked with this document this did NOT happen. I even looked at my archived copy to recheck and, yep, the phrase "Pulse Software" was properly spaced. If it weren't for the fact that it is only that phrase, and only those two lines in the TOC, that are being rendered incorrectly, I wouldn't be so frustrated.
I'm considering deactivating the Adobe font and installing Source Sans Pro locally, instead. It's the only thing I haven't tried, and I think the last time I worked on this document, it had been installed locally. Of course, the last time I worked on this document was in FM2019 and ... whatever version of Acrobat DC was available then.
Platform specs, in case it makes a difference:
Windows 10 Pro, 10.0.1.18363, update 2004
Dell Latitude E7470, 16Gb RAM
FrameMaker 2020 188.8.131.524
Acrobat DC Pro (kept up to date via subscription)
The last test: replacing the Adobe activated fonts with locally installed ones produced the same weird spacing result using File > Publish > PDF output and File > Save As PDF. It produced perfect copy using File > Print.
I'd still like to know what the <expletive deleted> is going on, but not enough to spend more time on it. Our current document isn't likely to be historically important or need to be opened in 50 years, so what I've got is likely to do well enough.
Does anyone think moving this to the Acrobat forum would be useful? It certainly seems to be an issue with creating PDF output.
It's happened again. So it's not these files, it's either an issue with the PDF engine in FM2020 or with the font (Source Sans Pro, activated through Adobe Fonts). This did not happen with FM2019 and the same font, so I'm inclined to think that it is an issue with the PDF engine.
Same file, using Opens Sans instead of Source Sans Pro. Spacing is even more messed up:
I got similar if not worse results converting with the font set to Calibri, but when I converted with Arial, ta-dah! It worked fine.
Open Sans, Calibri, and Arial are all Windows fonts installed locally.
Unfortunately for me, we can't use the Arial font. Open Sans is the corporate font, and Source Sans Pro is the closest we can come for our documents because it has the super/subscript glyphs we use when constructing fractions. Unless Adobe can figure out what is going on, it looks as if my coworker and I are going to be stuck using File > Print rather than the far faster Save as PDF.
(Why don't we use Publish? I don't know about my coworker, but I want the PDF saved where I want it, not where Adobe thinks it should go, so unless they let that be set as an option, it's not going to get used.)
And hopefully the last update until a fix is made: Pulkit Nagpal from the FrameMaker development team has been able to reproduce the error and there is now an internal ticket for it. Yay!
If anyone wants to vote for this bug to be fixed, see: FRMAKER-9315.
My current workaround is to save as PDF but I have the Publish pod set to run it through Acrobat Distiller. So far (knock wood) this has generated PDFs with no weird spacing issues.
Lin, have you forced the offending font to download?
I see what you're experiencing when either:
Try forcing Always Embed via the Fonts panel in the joboption. If not, choose a more standard Adobe font.
It happens with multiple fonts, and seems to be linked to whether its one of those fancy new combined font sets or the old-fashioned type that had a separate file for each typeface (you know, bold, italic, heavy, etc.).
The fonts are installed locally. (I gave up on activating them through Adobe fonts and downloaded them from Google Fonts. I think that was part of the troubleshooting I did early on.)
I always clear the Rely on System Fonts Only box (and why can't that be set to default? huh?) and the PDF job options is set up to embed the fonts.
As I said, Pulkit Nagpal was able to reproduce the error with the various fonts I reported on and they are working on it.
I haven't seen an issue in some time, but I also have things set up so that Save as PDF kicks off the Acrobat Distiller, which I had found was producing things correctly.
Hm. Our company font is Open Sans, and the Rely on System Fonts option is always activated, and I do not have any problems.
Where do you activate/deactivate this option? Your setting should not change back.
Print Setup, and I have to change it for each document.
I have set this in the control panel printer settings. This setting is kept.
Also note, this happened only in the generated TOC. The same font was used through the entire manual and had no issues anywhere else.
Corporate branding uses Open Sans and, now, Rubik, so changing fonts isn't possible. I was able to add Segoe UI so I could have the sub and superscripts needed ...
Have you forced Open Sans into the Always Embed?
If you like, you can create a short version of the book, package it, and send it to me offline to process on my system.
Both Open Sans and Rubik are set to Always Embed. When I was still using Source Sans, it was also set to always embed.