29
Using True Type Text in AutoCAD
Why is my text from AutoCAD not converting as searchable text in the PDF?
Creating PDF files from AutoCAD that allow text searching throughout the entire document and at the highest level of
compression, requires the use of True Type Fonts (TTF) in your AutoCAD drawings.
There are some conditions that must be met to ensure proper conversion of True Type Fonts in AutoCAD to PDF. These are
AutoCAD limitations in how it determines in the output stream to treat text.
1. The width factor must be 1.0. Modifying the width value in AutoCAD will prevent the TTF from converting as text to
PDF.
2. The oblique angle within the style must be set to 0.0. Modifying the oblique angle in AutoCAD will prevent the TTF
from converting as text to PDF.
3. The font must not be set to "Fit"
4. The font must have a Z coordinate of 0.0
5. If the font is part of a block the X and Y scale factors must be the same.
In addition the Adobe PDF Specification specifies a set of 14 fonts that must be available to every PDF reader: Helvetica
(normal, bold, italic, bold italic), Times (normal, bold, italic, bold italic), Courier (normal, bold, italic, bold italic), Symbol and
ZapfDingbats. So if you use only these fonts in your AutoCAD drawings you do not have to embed the fonts because even if the
user does not have the font installed the software that they are using to view the PDF file is supposed to have them. This is also
true for Apple, Unix, and Linux systems.
Many firms have AutoCAD drawings that contain more than one font. Some fonts are TTF and others are either SHX or custom
fonts. The SHX fonts don't convert as text on PDF files. They convert as outlines and curves which increase the PDF file size
dramatically. For a firm to simply stop using a custom font so that the PDF's its designers create are text searchable and smaller
in size is like asking an artist to paint with only one brush.
There is a solution. Firms that have custom fonts or SHX fonts that they use on a daily basis as a part of their drawing standards
can have these fonts converted into a TTF that will install as a Windows font. By converting their in-house fonts to TTF they
will be able to maintain their current drawing standards and enjoy the benefit of creating PDF's that are text searchable and
significantly smaller in file size.
TC Fonts is a company that will convert your SHX and custom fonts to true type fonts. You must be specific in letting them know
that the SHX font needs to be converted to true type font, because they also have software that will convert true type fonts to
many CAD font formats. Click here for the TC Fonts web site.
29
Why does my text look jagged from AutoCAD?
In AutoCAD's output SHX fonts are always treated as graphics and at times even True Type fonts are treated as graphics.
When you zoom in on the text in the PDF some of the characters may appear jagged. Quite often though when you print the
PDF to a printer or plotter the text looks fine.
It's common when zoomed in at 2000% in a PDF for the vector fonts to look like this:
There are several reasons for this and it is NOT a bug in the software, it's basically the rules of geometry.
1.) Vector fonts are simply a series of vectors (lines) in AutoCAD. When you create a PDF at say 300 dpi the endpoints of
every vector must start and end on a pixel location based on that 300 dpi. So 1/300 gives you a pixel every 0.0033 inches.
Now the above text is actually 0.03"x0.06" per letter in the PDF. That means that we have 9 pixels wide by 18 pixels tall to
draw the lines of the letter into. That's not much room at all when you think about it.
2.) When AutoCAD is calculating the endpoints for each line of the letter it must round up or down to the nearest pixel. It
does not know which direction may make it look better or worse, it just uses pure mathematics to determine the closest one
and that is what it outputs to us.
3.) You may say that you don't see this problem when you output to Adobe's PDF driver or to some other PDF driver. The
reason for that is that their driver is probably outputting at 600 or 1200 dpi. Fine for some drawings and better for text like
this but try getting AutoCAD to output a large format engineering drawing with Aerial images at 1200 dpi. The 300 to 400 dpi
range is what we have found works best overall. And remember, the text often looks perfectly fine printed out to paper, just
not when zoomed in 2000% or higher in the PDF viewer.
4.) True Type fonts on the other hand only need to have their start point for the line of text to fall on a specific pixel. Beyond
that the font information is either stored on the users system or in the PDF itself and the viewing or printing application can
render it at the DPI that the device can handle. So on screen it will render cleaner when you are zoomed in 2000% and when
you print if the printer is a 300 dpi printer it will be the same. But if the printer is a 600 dpi printer then it can render it at 600
dpi instead of the 300 saved in the PDF. But there are other inherit problems with using True Type Fonts in AutoCAD so
please see the following page before deciding to switch everything over to True Type Fonts - Click Here to Learn About Using
True Type Text in AutoCAD
5.) If you do want to raise the DPI to a higher value for the vector artwork but would like to keep the images at a lower DPI
to make a smaller file we can do that by downsampling the images that AutoCAD sends us. We unfortunately do not have
this as a standard setting but it's as a global setting in AcroPlot. Use the Setup->Options menus and then on the PDF Tab
you can set the downsample and DPI value for the basic types of images. As a general approximation going down by 50%
4
makes the images 200% smaller in file size because everything is a factor of 4. If you are printing directly to the PDF-
XChange for AcroPlot Pro driver then you will find these settings under the Graphics Tab of the drivers Printing Preferences.
This does cause longer processing times because AutoCAD actually sends us the image at the DPI you specify in the main
settings but then we downsample it to what you want it to be.
21
True Type Text Causing Text to be Clipped
Why is my AutoCAD text missing in the bottom or right edge or shifted on the top or left edge?
AutoCAD Margins Bug with True Type Text Causing Text to be Clipped
AutoCAD has had a bug that Autodesk refuses to fix since AutoCAD 2000. If you notice when you select the PDF-XChange
for AcroPlot Pro system printer in AutoCAD it will show that the paper sizes have a 0.125" margin even though the margins in
the PDF-XChange for AcroPlot Pro system printer is set to have a 0.0 margin. The reason for this is that somebody, way back
when, felt that they should consider any margin less than 0.125" as invalid (probably because in the old days printers couldn't
print all of the way to the edge). Autodesk has confirmed this as a bug years ago and assured us that it has nothing to do with
our printer driver.
Now normally this wouldn't be a big problem except Autodesk has another bug in the program (again which they refuse to fix)
which relates to how True Type Text is sent out. When True Type Text is sent out to a printer as text it has two parts. The first
part is the clipping plane that defines what the rectangle is that will clip the text if it is near the edge of a viewport or the edge
of the paper. The second part is the actual text information itself. The problem is that Autodesk uses the real margin of the
printer for the first part and the assumed (0.125") margin for the second part causing the text to be clipped wrong.
You can see the problem areas highlighted below:
So How do I Get Around the Bug?
1.) Use our AcroPlot Pro or AcroPlot Jr. interface. There are more features like per object transparency that is not supported
when going directly to the driver. We will also be releasing versions of AcroPlot Pro that support searchable text for shx and
True Type fonts that are not a 1.0 width factor that again cannot be accomplished when printing directly to a PDF driver.
2.) The best way around this is to use a pc3 and pmp file and define the margins in the pmp file to 0.0 for every size paper
you print to. This is essentially what we do behind the scenes when you use our AcroPlot Pro or AcroPlot Jr. interface.
18
3.) Or you could create a Pc3/Pmp (AutoCAD Plotter Configuration) file in AutoCAD and then use the Custom Properties to
get to the PDF-XChange for AcroPlot Pro printer driver. Then set the margin to 0.125" there and save the settings so only
AutoCAD will use the larger margin value.
4.) Another option is to set the Margin in the PDF-XChange for AcroPlot Pro printer driver to 0.125" for all of your programs.
We do recommend this option.
5.) Tha last option is to set the Pc3 file options to Create True Type Text As Graphics although this then creates larger size
files typically and you won't have searchable text. We do recommend this option.
Why do I not see this Bug with the Adobe PDF, AutoCAD PDF, or Other Drivers?
The AutoCAD DWF and PDF drivers both bypass the Windows System Printing and hence they do not have this bug in their
drivers. But trust us, they have plenty of other bugs with MText Masks, Wipeouts, and larger file sizes. This is why most of
our users continue to use AcroPlot Pro to create the best PDF files from AutoCAD.
The Adobe driver and many other PDF drivers are based off of a Postscript printing process instead of the Windows GDI
printing that our PDF Driver uses as well as the vast majority of printer drivers. Postscript drivers from AutoCAD always
convert text as graphics and they also don't support lines merge. So since the text is not sent out as text there is no clipping
planes to send out and the bug doesn't show up. Since the vast majority of users create PDF files through our programs we
were not about to go the postscript route and loose out on searchable text and lines merge for our users.
Again don't believe us, try printing it to the Microsoft XPS Document Writer that is included in Windows and you will get
similar results as seen below:
30
Why are AutoCAD's Textmasks Green or Other Colors?
This is a bug in the newer versions of AutoCAD (2011 to 2013 for sure) related to the combination of Textmasks and using Lines
Merge. It happens to all printer drivers (that support lines merge) when you enable lines merge support in the Pc3 file.
If you don't believe us try creating a DWF file with lines merge enabled and you will likely get weird colored or black
backgrounds in your textmask and the DWF output is a direct conversion from AutoCAD to file which bypasses the Windows
System printing. This to me say the problem lies solely in Autodesk's own code rendering the textmasks, not on our side or
windows side of things.
In our testing we tested the following output all of which displayed the problem when lines merge was turned on.
• Our PDF-XChange for AcroPlot Pro driver.
• Autodesk's own DWF6 driver.
• Microsoft XPS Document Writer.
• HP Photoshop Premium Inkjet Desktop Printer.
What we have found out so far is:
• It appears to only happen with legacy drawings or drawings that have had legacy blocks inserted. We have not been
able to reproduce the problem when creating a new drawing with Mtext masks and multileader masks.
• It only happens if you enable lines merge in the Pc3 configuration. Hence this is why it does not happen when going
to Postscript based drivers because they do not support lines merge.
• It happens to MText and Multileader backgrounds.
• It's related to the background mask. Select all MText and Multileaders in the drawing and turn the Background Mask
off and your output will be fine also. Try selecting one of the problem ones and increase it's background mask to 5.0
when you have it turned on and you will see a larger box.
• In our testing it seams like the background masks set to the drawing background tend to turn out green where colored
backgrounds will tend to be partially colored and partially black. Although at times some masks end up being multiple
colors.
• We have tested both with ctb files and without them and it happens both ways.
• Since it doesn't appear to be a problem in 2010 and prior versions and since 2011 I believe is when they implemented
per object transparency I would have to say that they screwed something up when they added that feature in. But
that's just my opinion.
• In my opinion Autodesk has never correctly implemented the whole black/white/background since they allowed you to
change the background color. But it looks like we are stuck with it for another 20 years.
Documents you may be interested
Documents you may be interested
