Xarab.shx Autocad Font
Aileen Modic
The PDFStyler uses TrueType font. So to be able to use AutoCAD SHX fonts, I think you'd need to convert it to TrueType and install it on the Windows machine. By doing that, you'd then be able to have access to those fonts You may want to look up ways you can convert a SHX to TrueType and install it to the machine.
There may be a format attribute on the AutoCAD writer though that may tell you the name of the font. You may want to review the documentation about Text Entities and check within FME if there are ones that match. From a quick look it looks like autocad_shape_name may hold this information. This could potentially help you map it when using the PDFStyler with the TrueType font installed.
One creative way to work around this issues is to try using the TextStroker (after installing the TrueType font to your machine). By using the TextStroker you can convert the text into polygon features based on the font chosen (which can also be set to an attribute, provided the name aligns with the TrueType font).
If you are looking to further style the features after the TextStroker, you could use the PDFStyler to change the colour of the polygon features - just a note that you will want to set the Line Width to 0 to have a better output. Another thing to mention is your file size may be a lot larger after using the TextStroker.
We use *.shx arabic fonts in our drawings. Everything was working flawlessly in AutoCAD 2015. We could write and print (to PDF or plotter for instance). But when we try to plot or convert a drawing to PDF in AutoCAD 2016, all *.shx fonts rotate and become upside down in the PDF file ro plot result !
Thank you for your concern. I have seen that xrab.shx file too and already downloaded and installed it. But unfortunately, this is not the one.
I am looking for the xarab.shx font.
If anyone has it please, kindly share.
my problem that I use SHX font (x-arab1.shx) in autocad with Arabic characters, so when convert CAD to GIS all annotations changed to English characters, also i cannot change style in Autocad because it converted to English characters instead of Arabic (same issue).
Sometimes the CAD to GIS integration just will not work the way we want it to work. I have found one big work around for taking text characters in CAD and putting them in GIS to look exactly like they do in CAD. Since I am not a CAD operator, I do not know the proper term that is used but from how I understand it in MicroStation is that you select all the text in the drawing and then "drop the line styles". This essentially turns all the text into actual line features. It is not ideal and creates a much larger file but when done properly, it behaves exactly like the CAD operator would expect.
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?
@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.
"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.
@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...
thx
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.
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.
@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.
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.
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 . A SHP file is essentially a text file and it defines the characters in the font.
The 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.
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.
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.
b37509886e