I have a stupid problem: grant proposals submitted to the NIH must be in Arial font, at least 11pt in size. I write proposals in 11pt font in Microsoft Word, and then convert them to a PDF. When I open the PDF in Acrobat, it tells me that the font is 10.8pt. This occurs on every single one of the lab computers (Macs), but does not happen if we convert the file on someone else’s Windows machine.
I never noticed this before, but apparently the NIH has started checking and rejecting grants that are not at least 11pt font.
In grant submissions, every bit of space is precious, so I don’t want to move up to an 11.5pt font (which comes out at 11.36 after conversion to PDF). Also, this is clearly a communication problem, not an actual font size problem - when we move the file to a Windows machine, 11pt takes up exactly as much space on the page as it does on a Mac, but the Windows machine tells Acrobat that it’s 11pt.
I’ve tried writing at 11pt and using the “Page Setup” function to scale up just a couple percent, and that works BUT it can’t be saved or re-opened. If I save the file and re-open it, the text is still displayed (and printed) in the scaled-up size, but it registers in Acrobat as 10.8pt. This happens even if the scaled-up font is HUGE: if I write in 11pt font and scale 200%, it will print at a 22pt size physically, but Acrobat still registers it as 10.8pt. So clearly Acrobat isn’t actually measuring the font size - it’s misinterpreting what Word tells it.
Has anyone figured out how to control how Acrobat interprets font size?
I’ve tried Word’s “Save As” function to create PDFs, or just printing, which gives you a “print to PDF” option. I haven’t tried any dedicated PDF conversion software. I think that one of my colleagues tried converting the file with Acrobat Pro. All three techniques produced the same problem - PDFs that say they’re in 10.8pt font.
WYSIWYG. Dollars to donuts you have a screen scaling problem, and the Mac’s are trying to give you exactly what they think you are seeing on the screen.
PDV and DOCX are both text formats, so you might be able to find something by looking at the file. As I recall, Docs is compressed last (zipped), and when you unzip it you get a mess of xml. As I recall, PDF is compressed first, and when you look at the text you see blocks of zipped binary.
Forgive me, but I don’t understand your suggestion. I’ve looked at every user-facing setting that I could find, but it sounds like you’re suggesting digging into the code. Could you clarify? Thank you.
Yeah, that’s the first thing I checked. Scaling is set to 100%, not “fit to page”. Given how much Macs like to manage your experience for you, it wouldn’t surprise me if that’s still going on somewhere in the background.
This isn’t going to solve the problem but it may explain it.
When Adobe Systems, Inc. started doing the printer thing with fonts and Illustrator they decided a printers point would be the basic unit of measurement for their printer-like applications. Adobe defined the point as exactly 1/72 inch or 0.013888. There’s some history, but for the sake of brevity, prior to Adobe a “real” printers point was defined to be ever-so-slightly less that 1/72 inch, 0.013837 inches. Naturally, when PDF was developed Adobe used Adobe points as the basic measurement system.
When those scamps at Microsoft developed Word they adopted a bizarre, never-before-heard-of unit called a “twip.” A twip is 1/20th of a point.
So Adobe uses points, exactly 1/72 inch. Microsoft Word uses twips, 1/20th of a point, however Microsoft defined a point.
I think the discrepancy is because MSWord is defining the point the pre-Adobe way (0.013837) and Adobe of course is defining a point as 1/72 inch (0.013888). I suppose it’s possible that the twips-to-points conversion is causing the discrepancy as well.
As an old printer it was bad enough that Adobe arbitrarily redefined a unit of measurement (but as I said, there’s some history there). But Microsoft went off the deep end with twips.
P.S. Some Adobe applications still provide the option of setting the “real” point value. So those guys knew what they were doing in redefining the point to 1/72 inch.
He/she reports the problem occurs only on Mac, though, not on Microsoft Windows. If the issue were what you say I would expect consistent behaviour from Microsoft Word across different platforms, and that the incorrect size would be something like 10.96 pt, closer to 11pt than 10.8 pt.
If someone on your team is a “computer guy/gal”, that person *might *learn something by looking under the hood so to speak directly at the innards of the DOCX file and the two PDFs converted on a Windows box and on a Mac.
A PDF file is mostly plain text for the control information and some embedded binary gobbledygook for the text content. So if a guru-ish IT guy/gal opens a pdf in an app like notepad, they can see the control innards such as font definitions. Figuring out what’s what is real work, but there’s probably some hints online.
A DOCX file is actually a zip file containing several plain text files that contain both the control info and the textual contents. The text files contain a large mass of complex XML, but the format of the whole thing is fully documented onine. To an even greater degree than a PDF, a computer goon can open a DOCX in an app like winzip, root around inside the txt files inside, and discover all sorts of interesting info or diagnose weirdnesses.
Whether that’s practical for anyone on your team is an open question. IMO even if it’s technologically doable for you folks it’s probably a red herring because it won’t tell you *how *to solve the problem. Other than what you already know: make the conversion on a Windows box, not a Mac.
I’m gonna bet ASGuy just above got real close to the source of the problem.
It’d be worth us all learning what Apple thinks is the right idea about the size of points. I could imagine Microsoft found itself in a crack where it could not achieve compatibility between Windows’s, Apple’s, and Adobe’s idea of what is correct. So they chose to make Word consistent between Word for Windows and Word for Mac. With the side effect that when the Apple OS “helps” Word for Mac create a PDF, some Apple-ness leaks in.
This is 100% guesswork on my part. But it’s plausible guesswork. I’ve certainly faced these kinds of challenges trying to build apps that work exactly the same under different OSes that have different ideas of what reality is.
Yes, but everyone in our lab uses Macs, so we’ve been sending it to the Grants office for conversion. Inevitably, when you transfer a Word file from Mac to PC, something gets messed up, so we end up in a reiterative process of “email file, receive back pdf conversion, notice that one of the figures has moved outside the margin, ask them to fix it, get new pdf conversion, notice that now the paragraph 3 pages down is messed up, etc.” And of course this is happening at grant deadlines, when we’re up against a clock and the Grants office is obviously very busy also. It would be much better if we could do it ourselves.
However, now that I think about it, the computers that run our confocal microscopes are Windows machines. It would be annoying to stop microscope users to convert PDF files, but at least we could do it ourselves. I’m at a conference out of state at the moment, but when I get back I will explore this option. I don’t know if all Windows machine work, or if there is something about the machine they’re using in the Grants office.
2 and 5) I haven’t tried Libre or LaTex recently. When I tried Libre years ago, it didn’t have Arial. The NIH demands Arial, only Arial, and none of those off-brand look-alikes. However, I’ll look into it again when I get back.
Huh. I’ve never looked at preflight before, it’s fascinating! However, it doesn’t report any font problems.
I tried resizing the font in Acrobat, but the Acrobat PDF breaks the texts into sections, about 4-5 sections per page. If you increase the font size within a section, the text does not flow to the next section, so you end up with ragged line breaks and overlapping text and it generally looks like something typed by a kindergartener. Super unprofessional looking.
You are shitting me. A “twip”? Was that a description of the guy who designed the system?
What kind of moron takes a well-established, universal standard of print and makes something like but not quite like that for their program for printing things? I mean, other than Microsoft and Apple, that is.
We do have competent tech support, but this guy has the kind of personality that gives tech support a bad name. If I can convince him that this is not a user problem, and I can convince him that it’s part of his goddamn job, and I don’t punch him in the face halfway through for being a smarmy condescending jackass, he might be able to dig out the problem. If that happens, I will receive a well-documented and beautifully detailed set of instructions for how to fix it myself the next time, along with an insulting note to not bother him any more.
Who can say? If I do get results, I’ll post them here.
There’s a joke in here about rotten apples spoiling the bunch, but I suspect it’s all Microsoft’s fault.
I picked a random PDF file off the Internet. It says it was produced by Microsoft Office Word 2007, PDF version 1.5. Looking at the file in a text editor (I did not even bother to uncompress it or load it into Acrobat), right near the beginning there is data like:
Oh, and Adobe points are definitely 1/72 in exactly. Note that those are bigger than the older 1/72.27in American points, so, again, I doubt that has anything to do with the issue.
ISTM the real origin of the problem isn’t “twips”. It’s that Adobe decided to redefine the size of a point to be something other than what the entire industry used for decades or centuries. Then everybody else had to decide how to react to Adobe’s pooping in the pool. I’m sure Adobe had their reasons although I have no idea what they might have been.
IMO “twip” as contraction for “twentieth of a point” is a pretty good bit of coinage.
As to why they bothered, it was probably an attempt to end-run around the inherent problems of doing decimal fractions on a binary computer. If 0.05 of a point is a small enough unit of measure for everyone to use, then they can store all font sizes as integer numbers of twips rather than as fractional numbers of points.
Which, if it had been more universally adopted, might have avoided exactly the kind of “close but no cigar” rounding errors that are plaguing our OP.
Eh, there are American points, Didot points, new Didot points, metric points, and so on, not to mention that the definition of the inch has changed slightly over the centuries. I don’t think Adobe deserves too much opprobrium (for introducing their unit, anyway), and it is certainly not their fault that Microsoft Word cannot handle simple arithmetic; it has worked just fine in LaTeX since 1978. Do you have any calculations explaining where the 11/10.8 factor comes from?
Things should be clearer once the OP can check the exact font size written in the actual PDF file.