Arial SHX file?
We've been using Arial.ttf for 99% of our labeling needs since I started working where I'm at. It looks great - nice and clean - but as a TTF it's had its quirks in both AutoCAD and BricsCAD. In AutoCAD, any time an elevation was applied to the text other than 0, the text got "fuzzy" (slightly, but not completely bold) both onscreen and when plotted. In BricsCAD, there's a strange quirk where any time an xclip line runs through the text in an xref, that text entity is very bold.
Bricsys is working on a fix for this, but they can't give me a timeline. In the meantime, it seems to me the best bet is to switch to an Arial SHX font, but the only ones I can find are just outlines, not solid text. Anyone have any ideas for where I can find one?
Comments
-
An SHX fonts cannot contain solid fills. So you should look for a font where outlines are filled with a pattern of pen strokes.
0 -
@Mike
That will be a struggle, and you should expect bugs in the future you have not seen yet.
I totally get that TTF's look nice. I still would recommend switching to Romansx.shx or other non TTF for main callouts in your drawings.
Our surveyors use TTF's, and it really bogs things down sometimes, besides the bugs.
I've watched this argument since TTF's could be used in autocad, and it just depends how dependable you want your processes to be.
Plus, the civil industry wants drawings that look like inked mylars, not word documents so we are biased.0 -
Personally, I'd much rather have SHX fonts just to avoid issues like this. Specifically, I want Arial because it's my boss's preference for everything but adjacent property text.
"Plus, the civil industry wants drawings that look like inked mylars, not word documents so we are biased."
Doesn't seem to be the case here; we're a civil firm and everything looks like a Word document.0 -
@Mike
Well, that is good. If he can embrace TTF and deal with its problems, he will get exposed to the fact we are on a wave and people like you are needed to ride it. Can't lose, right?0 -
That's the issue though: TTF is causing the problem, or rather a bug in BricsCAD having to do with XCLIP and text located in xrefs. I DON'T want a TTF, I want a SHX font.
0 -
@Mike
First, congratulations on getting Mike as a username, not an easy feat!
That TTF bug will not be easy to solve as fixing display stuff is never easy.
I'm curious what other things your boss holds onto that you could improve.
I've done acad programming for too long so might have some things you could use.
I get to run things at my place so I fix stuff as soon as solutions present themselves...
thx0 -
Mike,
I sent you a PM with a conversion done by FONTasm!. I don't know if that software is available now. FONTasm! does not optimize the converted file but the file does work.
A SHX font will not look as sharp as a TTF. This is because a TTF essentially draws a border with a 0 width pen then does a solid fill with no overrun, but a SHX draws the border with a pen that has width, so the character always has half a pen width outside the border.
I ran across a post that said blurry TTF are generally caused by Z values issues. Does flatten help?
If I wanted to regularly use a SHX version of Arial I'd start with with the available outline SHX and design my own fill. Not hard but very tedious. I can provide directions on how to do this if you'd like.
0 -
@James Maeding thanks, I'm surprised it wasn't taken as a username. The TTF bug isn't even a display issue; it's a plotting issue. Onscreen, everything shows up fine. As soon as the drawing is plotted out, any text located in the xref near the clipline is immediately turned bold. Bricsys is working on the issue but with no timeline able to be given. Otherwise, I'd be more than happy to just wait instead of finding a new font to use as a workaround.
0 -
@H Martin Shoemaker said:
Mike,I sent you a PM with a conversion done by FONTasm!. I don't know if that software is available now. FONTasm! does not optimize the converted file but the file does work.
A SHX font will not look as sharp as a TTF. This is because a TTF essentially draws a border with a 0 width pen then does a solid fill with no overrun, but a SHX draws the border with a pen that has width, so the character always has half a pen width outside the border.
I ran across a post that said blurry TTF are generally caused by Z values issues. Does flatten help?
If I wanted to regularly use a SHX version of Arial I'd start with with the available outline SHX and design my own fill. Not hard but very tedious. I can provide directions on how to do this if you'd like.
Thank you. I'll give it a try. I downloaded a pack of some 400+ SHX fonts, narrowed them down to the Arial look-alikes, then weeded them out further until I had just a dozen or so left. I then plotted them out and narrowed them down to just one which didn't show up as bold or fuzzy and had the necessary special characters.
I've found that in BricsCAD, TTF text doesn't show up as blurry or fuzzy when a Z value is assigned. This issue is specifically related to text located in the xref at the clipline.
I have the outline SHX of Arial, but I haven't a clue how to do the fill. Some help on that would be welcome.
0 -
Here is a quick guide to modifying fonts.
You'll want to read all of the 'Shapes and Font Shapes' section at >>> http://help.autodesk.com/view/ACD/2019/ENU/?guid=GUID-0A8E12A1-F4AB-44AD-8A9B-2140E0D5FD23 <<< before you start.
To modify a font you'll need to convert the SHX file to a SHP file. I use DUMPSHX.EXE from the old Autocad Express Tools for this. DUMPSHX runs in a CMD window and uses the syntax dumpshx -o
The SHP file has a header something like:
*0,4,Arial MT Light,0,0,0,34 [Regular] GGA:FONTasm!-v2.11
119,27,2,0The 27 is the height of the characters. Create a grid of equally spaced lines with a spacing of 1 unit and an origin of (0,0) that matches the height and that has a width about 150% of the height. Lock the grid's layer. On a different layer insert one character at (0,0). You may need to scale the character to get the height of the character to be equal to the height value for the file. Straight lines will end on grid intersections when the scaling is correct. Use a character that is full height (like B ) to determin the scaling required. Explode the character using TXTEXP then explode the resulting curves to get to just lines and arcs. TXTEXP can create polylines, which need to be reduces to lines and arcs. Most characters have white space after them. Look for the first instance of 8,(x1,y1) and the last instance of 8,(x2,y2) in the character definition. x1, y1, x2, and y2 are numbers. Draw a line starting at (x1,y1) that is x2 units to the right and y2 units up (or down if negative). This should give the end point.
Draw lines and arcs using grid intersections for endpoints to fill in the open space. You can dump something like HELV.SHX to see how it is typically done. I tend to not do the "tie the ends together" for the fill that you'll see in HELV.SHX. That made some sense with pen plotters and slow computers but with laser printers and fast computers it does not seem necessary.
You can now assemble the definition for the new character using the codes from the Autodesk document at the top of this post.
When You have the revised definitions use the COMPILE function in BcadTools Freeware to convert the SHP to an SHX file.
I have a lisp function that does all the heavy lifting for converting lines and arcs to a usable definition, but I haven't used it in a while and I need to write instructions before I post it. That may take several days to get to due to the holiday in the US. It does a very simple definition -- no subshapes (code 007), no scaled vectors (codes 003 and 004), no multiple displacement lines (code 009), all arcs are treated as fractional (codes 00A and 00b), and no vertical orientation (code 00E). It automates the process of converting the curves to a definition, which is rather painful if you have to do it manually. As long as your original font does not use scaled vectors and you don't need vertical it should save hours. If you need vertical that is fairly easy to add manually.
0 -
Correction: The height above the baseline is 119. The 27 is below the baseline.
0 -
@H Martin Shoemaker
I just realized your username does not play well with intellisense when doing an @ thing.
Anyway, great info on the font making. I would love to try the lisp.
thx0 -
James,
I've attached a lisp function that works for simple fonts. No vector multiply or divide supported.
The rules are:
- Only lines and arcs are allowed. If you use TXTEXP to get a base character for modification you will have plines, including segmented pline "arcs". These will have to be converted to lines and true arcs.
- White segments are 'move with pen up'. Any other color is 'move with pen down'.
- The segments have to be continuous. If you were coding by hand 'move with pen up' segments would not be drawn. Here they need to be drawn in white. After you have a start-to-finish collection of lines and arcs you can offset some segments if it helps to make the segments selectable in order. The function only looks at delta x, delta y, and bulge and does not check to see of the segments are actually touching.
- The function prompts for the (0,0) point then prompts to select segments in order. For the "font test.dwg" the segments would be selected in the order white (from 0,0), red, yellow, green, cyan, blue, magenta, orange, dark green, then ending white.
For the sample the original SHP file contained:
*UNIFONT,6,TestFont
96,14,2,0,0,0*00042,38,ucb
2,8,(14,50),1,8,(39,0),12,(25,-25,-53),12,(-25,-25,-53),8,(-39,0),8,(0,96),
8,(36,0),12,(23,-23,-53),12,(-23,-23,-53),2,8,(43,-50),0The output of font.lsp is:
38
"2,8,(14,50),1,8,(39,0),12,(25,-25,-53),12,(-25,-25,-53),8,(-39,0),8,(0,96),
8,(36,0),12,(23,-23,-53),12,(-23,-23,-53),2,8,(43,-50),0"The conversion of the Arial outline SHX to a filled version is much more involved. In the version I have made with FONTasm! they use a factor of 6 and an above the baseline size of 119, which makes the characters 714 units tall above the baseline as designed. I think it will be possible to write interactive code to duplicate the outlines on a character-by-character basis and to create a fill. If I do so I don't think I'll try to support vertical text. I also expect to have the user at least pick the areas to fill. It might be possible to automatically find the areas to fill but I suspect that getting that code to be reliable would take more time than is reasonable.
0
