Text not WYSIWYG

[Revitator]

We're just evaluating Revit, and have hit a bump: We use a TTF font called 'Gill Sans MT', and in Revit it seems not to print WYSIWYG.

I'm attaching a couple of screenshots: 'Screen.jpg' and 'Print preview.jpg'. You can see (if you look closely) that the letters in the Gill Sans font are different between the two. In the Print Preview, they're bigger and squashed together.

You'll understand, we use this font all the time in other applications (Word, graphics, etc, etc.), and haven't noticed this anywhere else.

It's only a little thing, but it makes the drawings look lousy.

I'd appreciate any insight as to what might be going on here.

[hand471037]

I'd appreciate any insight as to what might be going on here.

What kind of printer is it?

IIRC, when you hit the 'preview' button, what you see is what's going to print, and it's based upon the driver you're using for the printer. Change the driver settings, and the preview will change, and the print job.

So are there any differences within the driver or settings between Word & Revit? Does Word preview the same way? Are you sending the fonts to the printer or not? Does it do the same thing when using Raster printing out of Revit?

[sbrown]

Print preview is not an accurate rep of what gets printed, have you printed and the actual print looks diff. from if you print in word to the same printer?

[Revitator]

Thanks for your replies, Jeffrey and Scott. I've done some more checking:

I've tested against an HP 5500 plotter, an Oce 9300 plotter, a Ricoh 3800 colour laser, and an Olivetti D-20 photocopier: The problem is the same on all of them. Prints & previews from Revit are not WYSIWYG (They're the same on all the printers, they just don't match the screen). Prints and previews from Word are OK.

I'm just using the same (Windows) printers (Start menu/Printers and Faxes) to print from Revit as I am from Word, etc. So you'd *think* that the driver settings would be the same. I'm not sure whether the fonts are sent to the printer in each case, but I suspect that they're all using different file formats to send the files to the printers (HPGL, PCL, Ricoh's own proprietary format, etc), which might imply that it's not a driver issue (would you agree?).

I've also checked the Raster vs Vector setting in Revit, and that doesn't seem to make any difference.

Hmm. I'm stumped again. Something to do with the way Revit picks up the font metrics from this particular font? (says he, clutching at straws)

Thanks again: Any further insights welcome! :)

[Allen Lacy]

This has been a known issue for some time (http://forums.augi.com/showthread.php?t=594). As I recall someone from support contacted me about this, but it seems that it's still an issue.

[sfaust]

We used a font called "graphite" which would print significantly smaller than the size given, but it previewed the same as it looked on the screen. When we exported to ACAD, it would jump up to the correct size, and therefore make everything too large. This font also worked fine in Word, etc. but would not work in notepad. We sent it off to support & they said that the font was slightly corrupt. We switched to a different one & have not had a problem since. Don't know if this is anything similar, but thought I'd mention it...

[Revitator]

Thanks, Allen and Steve. That's clarified my thinking.

It sounds as though the font we're using may be slightly corrupt (non-standard?), and Revit may be being more exacting than some other packages when it uses fonts.

I'll see if I can post a copy of the font up to support, and in the meantime figure a workaround.

[hand471037]

I'll see if I can post a copy of the font up to support, and in the meantime figure a workaround.

When I first got into Revit, I was working at a place that used a custom font for everything non-CAD (and the standard RomanS font there). I spent a fair amount of time starting to redo all the out of the box Revit families to use this other font. It was taking way too long, and in the end our 'custom' font that was choosen by a graphics firm was 99% the same as Arial, and the whole time our CAD had never matched the rest of the firm's documents (with no one caring), so we decided to just use the out-of-the-box Arial font.

And only two people out of 70 even noticed.

So... while the issue you're running into isn't great, and it should work the way you want, you might want to ask if you really need this or not before you spend a ton more time on it.

[Revitator]

Thanks again, Jeffrey

Yes, we could go to Arial for most of the text on the drawing. The only prob. is that our titleblock uses Gill Sans for the firm's name/logotype. My workarounds for this would be to either use a raster image (easy but not very nice), or to trace around the letterforms and make a series of filled regions (tricky but better). Unless you all have any other ideas? :)

[hand471037]

Yes, we could go to Arial for most of the text on the drawing. The only prob. is that our titleblock uses Gill Sans for the firm's name/logotype. My workarounds for this would be to either use a raster image (easy but not very nice), or to trace around the letterforms and make a series of filled regions (tricky but better). Unless you all have any other ideas? :)

If you've got a copy of Adobe Illustrator around, you can convert your Firm's logo into pure lines, and then export it as a DWG/DXF, and then import it into Revit for use as a Fill Region Sketch...

But this sometimes won't fly if the lines are too small, Revit will freak out unfortunately. But it's worth a try.

[sfaust]

My old Firm had a rather complex logo with lots of filled regions & stuff. We just used a jpg with decent resolution and it worked pretty well FWIW...

[Revitator]

Thanks again, Jeffrey and Steve.

In the end, I've done as Jeffrey suggested and cranked up Illustrator. And yes, some of the shapes failed to import since they had lines that were *too small*. And then, when I got them in and tried to edit them (to make the shape outlines invisible), Revit complained that the splines were self-intersecting.

So, most of the final thing is redrawn splines in the shape of the original letters (with apologies to Eric Gill, whose incomparable typography I've crudely b*****dised). :)

Thanks again for all your help and advice.

[Andrew Dobson]

I've been hunting around for this thread for ages and finally found it!

Our company has recently changed our font to Gill Sans. We have purchased Gill Sans opentype for use with Adobe and most general windows programmes, but opentype fonts don't work with Revit or AutoCAD. Instead, I'm using Gill Sans MT, which installs with Microsoft office (but I dont think works with Adobe).

We have the same problem experienced by others earlier in this thread, i.e. it looks fine on the screen, but when you print it directly to a hardware printer, all of the spacing messes up. This problem is only with Revit, any other programmes (including AutoCAD) print Gill Sans MT with no problems at all.

There is a work around - print to PDF first (I use CutePDF) and then print the PDF to the hardware printer, but this isn't really good enough - especially as Autodesk have no interest in PDF in Revit, its perverse that this is the workaround....

Does anybody else have these problems?

[irneb]

Have you tried exporting to DWF and then printing from Design Review? I know stuff like transparencies get all messed up if you print to PDF.

[rauerbac423417]

I'm having this problem, too, which is amazing, since this thread appears to have been started 8 years ago. I tried the DWF workaround, and it's problematic because it turns out that Revit is shrinking the text in its views. I've attached a shot of the Revit view versus the Design Review view, where you can see that the text looks correct when printed this way, but is clearly larger than it appears in Revit.

Some people have mentioned that they worked around with different PDF printers, but I've tried Adobe, Blubeam, PDFCreator, and CutePDF; all have the problem of squishing the text together. In addition, someone mentioned that they changed a setting to "Outline" but I've seen no place in any of the options to do this. Someone also mentioned that various print drivers are able to work around this problem, however, we need to print to PDF in order to coordinate with our out-of-house printers and subs.

I'm new to this whole thing - how do we get Autodesk to fix the problem?

Any help would be appreciated!
-R

[MikeJarosz]

The issue here is copyrighted fonts. Fonts do not grow on trees and are not free except for those included with Windows and are certified by Microsoft. As Andrew indicated, his firm purchased Gill Sans. Did you read the conditions? Most likely you may only use this font at your office location and are not allowed to distribute this font, which means your logo on the titleblock won't work when you send it to the structural engineer, unless you include the font, which is probably a copyright violation. Almost nobody understands this and are mystified why it doesn't work everywhere. It is not the software's fault, it is the font's fault.

Because it is not certified by MS, you are likely to have problems with other Windows compatible software, not just Revit, as Andrew discovered. And not just software, but hardware too. Rather than repeat previous rants of mine, look up my previous discussions about fonts on this forum. My recommendation is to give up the custom font and live with one of the many MS certified fonts.

[irneb]

My recommendation is to give up the custom font and live with one of the many MS certified fonts.For the time being I'd advise the same thing. This does not mean that you should never use custom fonts, it's just that Revit's one of the programs which don't work well if the font isn't exactly as per the norm. Others I've seen doing similar is PhotoShop, Adobe Illustrator, Scribus, CorelDraw, Open Office, etc. Though they usually print the same as they display, it's just noticeable when you open one of their files in another program.

Methinks the major issue is the method of sizing fonts. There are 2 main units which could be used: point (http://www.computerhope.com/jargon/p/point.htm) and pixel (http://www.computerhope.com/jargon/p/pixel.htm). Then there may even be the "original" typesetting measure called a pica (http://www.computerhope.com/jargon/p/pica.htm), or these days in HTML you also get em space (http://www.computerhope.com/jargon/e/emspace.htm). And if you look at the history of these 4 measurement units, you'll realize they've changed in definition over the course of their lives (e.g. points {pt} have changed in the 80's and 90's). So the program may be using an older / newer variant of these.

Further to that when making a TTF/Open Font, the designer chooses which of those he's defining the font in. Then the actual file has an internal setting showing how it's glyphs map onto these units. E.g. from the TTF spec (from Microsoft) true type fonts specify how much "space" an EM Space consists of, but does not specify exactly what that measures too. There are 4 fields which govern this scaling in conjunction with each other. Some fonts would only use one or two of these to define their correct size, while others may use a different set or even all 4.

Then even more complicating is the fact that each character (glyph) may have its own min/max sizing inside that font and have such things as margins (top/bottom/left/right/baseline), and not to forget a scale factor of its own.

Now Microsoft has developed a library of code which deals with these things consistently (or rather it "should"). Other programs may/may-not be using this library. E.g. you might notice the difference in font sizes between Internet Explorer and FireFox and Chrome when viewing the same page on each in turn. This is mainly due to this font-engine. FF and Chrome use their own rendering system and does not rely on MS's libs, while IE uses the standard Windows Font Engine.

Unfortunately the Windows Font Engine is a bit long in the tooth, it was originally designed in late 80's early 90's for use in Win1 to 3 and OS2. Some minor updates for 95/98, but since then very little has changed. This means that some things are not possible using this engine, that's usually why a program would use something like Open Font or such (it's a newer, more capable library).

I'm not entirely sure what Revit is using, it may be using the Windows lib, or any of a number of others, or even have its own built-in (similar to what ACad does). But what I'm sure about is that it uses at least 2 different libs: i.e. one for displaying on screen and another when printing. This is where the issue comes about: it might be that one of these libs use some setting in the font different to the other (or could even ignore a specific setting, where the other doesn't). Thus if the TTF file has such setting you'd find a difference between the view/print, but when the TTF does not use that setting the difference is gone.

Further, saying that Revit should simply use the same lib in both cases: is saying much more than just a quick coding change. E.g. the lib used for viewing might be specially designed to accommodate graphics acceleration and the lib used for printing might be special to interacting with printer drivers. Or more probably it uses the built-in libs which simply send RAW EMF (Enhanced Meta File) data to the printer driver, which then in turn uses some other lib to convert that to its internal representation (e.g. to change into a PostScript font and its text for PDF, or to change into a bitmap for printing as a Raster image). So simply "plugging" in another lib might cause many other issues. So this is probably something which will take a long time to be "fixed" in future Revits. --- and THAT is why I agree with Mike: find a font which looks similar enough and doesn't cause these issues.

[MikeJarosz]

Thanks irneb...... for adding a technical explanation to this discussion.

I studied architecture at Pratt Institute in New York, a college specializing in the fine and applied arts. Besides architecture, I was surrounded by students in fashion, painting, sculpture, advertising and much, much, more. There were classes on book design and fine typography. Every division has a student gallery. I was totally fascinated by the typography courses. Although I was in the architecture school, I could visit the book design gallery. One of the student assignments was to create a new font. Since then, I have always been aware of fonts.

And fonts are a business! That's why I pointed out the copyright issue. Ever wonder why Windows has Swiss but not Helvetica? There's a whole story there. Successful fonts are quickly copied by rival font houses. Swiss is actually a copy of Helvetica. Times New Roman is a copy of Times Roman, and so on. To protect themselves, some typographers don't even create full alphabets, just to limit it's usefulness. Chermayeff and Geismar did this with the Chase Manhattan logo font.

But in this age of rampant piracy.........

[irneb]

But in this age of rampant piracy.........That's a whole different matter. You get piracy and then you get Fair Use. But the line between the 2 is blurred. There is some light at the end of the tunnel though: http://downloadsquad.switched.com/2010/07/26/judge-rules-that-circumventing-drm-is-not-illegal/

I.e. it's not "illegal" to circumvent anti-piracy controls if the end result is not to be an illegal act (e.g. like pirating movies to sell them is illegal, but circumventing DRM on DVD's which you own yourself for the express purpose of backing it up for yourself is not).

The idea behind "Fair Use" is quite logical if you think about it. For media it's a bit weird though. If we (arch / eng) had the same copy-right laws working for us, then on each building we've designed we'd be entitled to royalties for every single person walking into the place in perpetuity. That's what FU is trying to demolish, sure the programmer and the artists are entitled to payment for their work, but not to infinity for a single piece are they?

In this context (fonts) would it be acceptable to think a designer should be paid 50 years after they've finished making such font by every single person who views/modifies text written in it? And even if you think of someone using that font 50 years later to make a new document, should the designer still get paid for the month to a year's worth of work in making such font? Also, is it "Fair Use" to send digital material to others which include the font so it can be viewed / printed as intended? Surely the textual content is the crux of the material, not the font it is written in. So the producer of the text pays the font designer to use that font (up to a point which should be defined as "Fair"), but the consumer(s) of the text should not have to pay the font designer.

That's where these legal issues come to play, you send digital material to others for use in a collaborative effort. Within this is packaged copyrighted items. Should the collaborators also have to pay since they use the document you've sent them? And should everyone always pay for its use in perpetuity?

[MikeJarosz]

Whoaaaaaaaa........ Don't confuse the messenger with the message. It's clear you don't like the copyright laws, especially when they make you pay "in perpetuity". Because I'm reporting about them doesn't mean I agree with them. First of all, copyright laws differ from country to country. Right now for example, the copyright on American pop music from the 50's (think Sinatra) in Europe have expired, and budget labels are popping up all over Euroland with royalty-free music. Those same recordings are still under copyright in the US. Record companies are going crazy over here to keep the pop-ups out. I buy lots of the Euro albums by email at half the price they cost over here. It's not clear (to me) if I'm breaking any laws.

Now, back to software copyrights. A company I know was challenged by Microsoft to prove they were not violating their software licenses. Microsoft subjected them to what is called a "software audit". Subsequently, MS found illegal copies. They gave the offending company two choices: pay a $500,000 fine and legitimize all their MS installations OR Microsoft would pull all their licenses to all MS software. Imagine doing business with no Word, no Excel, no Xbox, NO WINDOWS!!!!!! They paid the $500K.

To most of the people using Revit in architecture firms, these considerations are from outer space. And the likelihood of Autodesk secret agents in black leather and dark glasses descending on them truly remote. But you can be sure Autodesk has a well staffed legal department, ready to pounce when given the order. So, decide for yourselves what you want to do. I am a BIM manager for a firm that has a corporate owner. We have a full time legal department that reviews all these things, so I obey the letter of the law.

[irneb]

You might be seeing my post as antagonistic, it definitely isn't ... to you ;) ... It's against IMO unfair practises in the media / software sectors.
To most of the people using Revit in architecture firms, these considerations are from outer space. And the likelihood of Autodesk secret agents in black leather and dark glasses descending on them truly remote. But you can be sure Autodesk has a well staffed legal department, ready to pounce when given the order. So, decide for yourselves what you want to do. I am a BIM manager for a firm that has a corporate owner. We have a full time legal department that reviews all these things, so I obey the letter of the law.I've got no issue about paying for software to be owned. And even the "subscription" idea is fine by me - i.e. you're paying a rent such that you always keep up to date with the software. It's up to the customer if they want that. But consider some guy "wanted" an old ACad R10 for DOS, Adesk doesn't sell those anymore, but could he buy it from someone who had the license for the past 24 years? That's more in-line with the font problem, i.e. the font may have been designed several decades ago - no further updates on it.

I'm just saying: you should pay for "effort", not for content when it comes to these information / data / systems products. And you're right about current laws varying between countries, and also some being enforced while others seem to "let it slide". As a matter of course I know of at least one firm over here who's got burned by ADesk (not just MS). And several by Adobe. I'm in agreement with ADesk/MS/Adobe on those scores, those guys did use non-licensed software (i.e. cracked the registration) of rather new stuff (i.e. version from last few years to current). That's clearly illegal.

One thing about the subs is you don't actually "own" the software. Only the right to use it for the time ADesk specifies. In that case you never had the license to resell. But if you outright bought the license, you should have the same rights as if you bought a car now shouldn't you? (i.e. be able to sell that to someone else) Now if you've similarly "rented" the font for a specified time period, I could understand that. But I've never heard of fonts being licensed in that manner, it just doesn't make sense since they get very few updates and/or fixes in the course of their lifespan.

[MikeJarosz]

This horse is nearly dead. But I can't resist one last whipping. Wiki sums it all up here. Note the section on lawsuits.

http://en.wikipedia.org/wiki/Intellectual_property_protection_of_typefaces