Arial Tur shows in style dialog instead of Arial

Arial Tur shows in style dialog instead of Arial

CADdaddy.com
Collaborator Collaborator
3,074 Views
17 Replies
Message 1 of 18

Arial Tur shows in style dialog instead of Arial

CADdaddy.com
Collaborator
Collaborator

Hi All,

 

I'm trying to change the font to Arial using the LISP command (command "-style" "test" "arial.ttf" "" "" "" "" "")...but when I look at the resulting style it appears as if "Arial Tur" is being used instead.

 

This happens in a brand new drawing where I've create a style called "test" using the font romans.  Then I run the LISP above to change the font to Arial and this is what I see:

TUR.PNG

As far a I can tell there is no font installed on my machine called "Arial TUR" and there is no family member of Arial called "TUR".  My understanding is that TUR stands for Turkish. 

 

If I use the dialog to manually set the font to Arial....it works fine!  If I try to do it programmatically it ends up TUR. 

 

Any advice would be appreciated.

 

James

0 Likes
Accepted solutions (1)
3,075 Views
17 Replies
Replies (17)
Message 2 of 18

CADdaddy.com
Collaborator
Collaborator

There's been a development...

 

I was looking into the Windows side of things thinking that maybe some font setting was causing the problem.  The "Hide fonts based on language settings" looked promising...but the box was already unchecked.  When I CHECKED the box all the language fonts appeared in the Style dialog box.  So yes, there was a hidden Arial TUR.   And unbelievably, that made changing the font programmatically work correctly!  It looks like a Windows bug to me. I think that check box is doing exactly the opposite of what it's supposed to do and it's causing AutoCAD to act weird.  If somebody from Autodesk is reading, Microsoft would probably respond a lot quicker to this issue if you brought it to their attention instead of me!

FontSettings.PNG

AllLanguages.PNG

 

Regards,

James

0 Likes
Message 3 of 18

dlanorh
Advisor
Advisor

 Try this

(setq nw_font (strcat (getenv "systemroot") "\\Fonts\\Arial.ttf"))
(command "-style" "test" nw_font "" "" "" "" "")

It may just be an autocad/windows path problem

I am not one of the robots you're looking for

0 Likes
Message 4 of 18

CADdaddy.com
Collaborator
Collaborator

Thanks for that...but now the glitch is weird in a different way.

 

  1. I didn't notice it before, but now, whether the box is checked or not, all the Arial fonts in other languages always show up in AutoCAD text style font list.  I restarted the machine after each check and uncheck of the box.
  2. The Arial fonts in other languages ONLY show up in AutoCAD and in none of the other 4 applications that I tried.
  3. The upside is, whether the box is checked or not, AutoCAD seems to accept the change of font programmatically now.

James

0 Likes
Message 5 of 18

CADdaddy.com
Collaborator
Collaborator

I'm closing in on the problem.  It has to do with extended data.  When I look at the xdata attached to the text style:

 

(entget (tblobjname "style" "standard") (list "ACAD"))

 

This is what gets returned:

 

((-1 . <Entity name: 22e434b2110>) (0 . "STYLE") (330 . <Entity name: 22e434b2030>) (5 . "11") (100 . "AcDbSymbolTableRecord") (100 . "AcDbTextStyleTableRecord") (2 . "Standard") (70 . 0) (40 . 0.0) (41 . 1.0) (50 . 0.0) (71 . 0) (42 . 0.2) (3 . "arial.ttf") (4 . "") (-3 ("ACAD" (1000 . "Arial TUR") (1071 . 41506))))

 

Notice that in the xdata "Arial TUR" is used instead of "Arial".

 

Does anybody have any idea how or why this could happen.  I don't see any message when I open the file that any substitutions have been made.

 

I explored the possibility of editing the xdata but it seems that LISP tools don't let you modify xdata in text style tables....or maybe I'm doing something wrong.

 

Any help would be appreciated.

 

James

 

 

 

0 Likes
Message 6 of 18

dlanorh
Advisor
Advisor
Are you looking to modify the xdata or load the correct font?

If the latter, and this may sound stupid, but is there an extra t in the lisp code i.e. "arialt.ttf"? I wouldn't be the first time a typo has weird effects.

I am not one of the robots you're looking for

0 Likes
Message 7 of 18

CADdaddy.com
Collaborator
Collaborator

Not a chance.  I've done a pretty airtight test just to prove the problem:

 

I started with a completely clean empty drawing with one style named "Standard" and manually changed the font to Arial and then ran the following test:

(defun testArialTur ()
(setq e (tblobjname "style" "standard"))
(princ "\nFont is currently Arial.ttf and xdata shows same")(terpri)
(princ (assoc 3 (entget e )))(princ (assoc -3 (entget e (list "ACAD"))))

(princ "\nProgramatically setting font again to arial has no effect")(terpri)
(command "-style" "new" "arial.ttf" "" "" "" "" "")
(princ (assoc 3 (entget e )))(princ (assoc -3 (entget e (list "ACAD"))))

(princ "\nSetting to different font")(terpri)
(command "-style" "standard" "calibri.ttf" "" "" "" "" "")
(princ (assoc 3 (entget e )))(princ (assoc -3 (entget e (list "ACAD"))))

(princ "\nSetting font to Arial again...WTF?")(terpri)
(command "-style" "standard" "arial.ttf" "" "" "" "" "")
(princ (assoc 3 (entget e )))(princ (assoc -3 (entget e (list "ACAD"))))
(princ)
)

Here is a clip of the output that shows the font name (dxf 3) next to the xdata  (dxf -3) each setup of the way.  Notice the last line after resetting font to Arial the font name does not match the xdata font name.  It's the xdata font name that is displayed on the screen in the font dialog box.

Command: (TESTARIALTUR)
Font is currently Arial.ttf and xdata shows same
(3 . arial.ttf)(-3 (ACAD (1000 . Arial) (1071 . 34)))
Programatically setting font again to arial has no effect
(3 . arial.ttf)(-3 (ACAD (1000 . Arial) (1071 . 34)))
Setting to different font
(3 . calibri.ttf)(-3 (ACAD (1000 . Calibri) (1071 . 34)))
Setting font to Arial again...WTF?
(3 . arial.ttf)(-3 (ACAD (1000 . Arial TUR) (1071 . 41506))) Command:

This does not happen on my personal computer but tested positive on two computers on a client's network.  It's as if these two computers think (wrongfully) that the language is set to Turkish and are automatically selecting the Turkish language character set variant of Arial.ttf.

 

How could this be happening?  I've checked the Windows registry an there doesn't appear to be a manual substitution in effect:

arial in registry.PNG

 

 

James

 

0 Likes
Message 8 of 18

dlanorh
Advisor
Advisor
It could be an incorrectly set or additional code page or even a keyboard driver. Perhaps , at some point, the client has loaded a drawing composed on a turkish language or dual language version of Autocad or windows. This has happened to me at various times with English (bz), English (nz) and English (za). Since assigning an additional (German) keyboard, the problems have ceased.

I am not one of the robots you're looking for

0 Likes
Message 9 of 18

CADdaddy.com
Collaborator
Collaborator

After speaking to Autodesk you seem to be on the right track with the code page.  Here some further info/observances:

 

  1. There appears to be a few drawings on the server that were created on a computer where the Turkish language was in use.  When those drawings are opened, the Turkish "code page" is loaded (This is what Autodesk Support told me on the phone).
  2. It appears that, if a drawing using a Turkish code page is loaded into the editor (even if the current language is not set to Turkish AND no Autodesk language pack is installed) that same code page gets loaded into the editor and persists throughout the entire AutoCAD session (until AutoCAD is restarted).
  3. Lets say a "clean" drawing is loaded into the editor (that is not using Arial TUR) but the Turkish code page has been previously loaded into the session.  The foreign code page does not automatically change existing styles using Arial to Arial TUR.  But, if the font is changed to Arial programmatically, AutoCAD automatically assigns the font that matches the current code page.   This behavior is NOT exhibited if choosing the font manually through a dialog box. 
  4. You can tell when the TUR code page is currently loaded in this manner:  If you manually (using the STYLE command) set the font to anything besides "Arial" and then try to programmatically change it to "Arial".  If you see "Arial TUR" in the style dialog: LOADED.  If you see just plain "Arial": NOT LOADED.
  5. Cleaning files of this issue is difficult.  I've tested a bit and have noticed that even if I clean a set of "base" files (with no xrefs attached), the problem appears to persists in the parent xref.  I need to do more testing to make sure.
  6. This behavior can be reproduced on any other computer on that network or off that network.
  7. No adverse behavior is noticed on the drawings since nobody in the office has the Turkish language pack loaded. 
  8. This explains why this problem only exhibited itself after I started running scripts for this office to change the fonts used in their font styles.  Please don't ask why I didn't use the font mapping feature.  We considered that too....it's complicated.  If I had know the result would be mangles font names I think I would have gone with mapping--guaranteed.

 

James

0 Likes
Message 10 of 18

dlanorh
Advisor
Advisor
Thanks for the update.

I am not one of the robots you're looking for

0 Likes
Message 11 of 18

ronjonp
Mentor
Mentor

Thanks for looking into this .. it's been plaguing me for quite some time. One horrible side effect I've seen of this is when an mtext/mleader text is modified, the font gets hard coded into the texstring:

 

Ie .. start with 'ASDFSFASFDF' .. then add something to that string 'TEST' for my example and the result looks like this:  "{\\fArial CYR|b0|i0|c204|p34;ASDFSFASFDF}TEST"

 

Quite a mess!

0 Likes
Message 12 of 18

CADdaddy.com
Collaborator
Collaborator

I was working on a portion of a project and I found that one xref file was causing the problem.  I audited the file and reopened it in a new session and that fixed the problem. As soon as the xrefs were cleaned, the parent file no longer exhibited the problem (whereas it did before).

 

So, it appears that the problem is detectable and fixable. 

 

I wrote a fix program that attempts to fix the problem and prompts with a dialog if it fails.  That way, my script will be halted by the dialog so I can figure out which file is corrupt before the issue get propagated throughout the rest of the files to be processed.

(defun FixARIALtur ( / stylelist style oldstyle e FontName rtn)
	;(FixARIALtur)
	(setvar "cmdecho" 0)
	(setq rtn t) ;return true by default set to nil if test fails.
	
	;Changing the font in a text style programmatically causes the issue so change
	;the arial font to something else (calibri) then back to Arial should trigger
	;the problem if the problem persists in the file.  This checks each style that
	;uses Arial font.

	(setq stylelist (ccGetStylesUsingFontWC "ARIAL.*")) ; the period excludes all Arial family fonts like Bold, Italics, etc.
	(foreach style stylelist
		(princ (strcat "\nProcessing Style: " style))
		;(setq style (nth 2 stylelist))
		;(setq style "carducci-std")
		(command "-style" style "calibri.ttf" "" "" "" "" "");Change style to use some other font.
		(command "-style" style "arial.ttf"   "" "" "" "" "");Then change the font back to Arial...that fixes the problem
		
		;test to see if fix was successful

		(if (setq e (assoc -3 (entget e (list "ACAD"))))
			;The fontName will have a name extension like "Arial TUR" if there is a codepage problem
			(setq fontName (cdr (assoc 1000 (cdr (car (cdr e))))))
		)
		(if (= fontName "Arial")
			(princ "...All good.")
			(progn 
				(alert "Arial TUR fix failed.  Restart session before proceeding with any scripts that change fonts")
				(setq rtn nil)
			)
		)
	)
	rtn
)

To clean a project care must be taken to work your way up the xref chain since a corrupt file can corrupt the parent xref (and the session) causing the need to constantly restart the session during a script.

 

James

0 Likes
Message 13 of 18

ronjonp
Mentor
Mentor

@CADdaddy.com wrote:

I was working on a portion of a project and I found that one xref file was causing the problem.  I audited the file and reopened it in a new session and that fixed the problem. As soon as the xrefs were cleaned, the parent file no longer exhibited the problem (whereas it did before).

 

So, it appears that the problem is detectable and fixable. 

 

I wrote a fix program that attempts to fix the problem and prompts with a dialog if it fails.  That way, my script will be halted by the dialog so I can figure out which file is corrupt before the issue get propagated throughout the rest of the files to be processed.

(defun FixARIALtur ( / stylelist style oldstyle e FontName rtn)
	;(FixARIALtur)
	(setvar "cmdecho" 0)
	(setq rtn t) ;return true by default set to nil if test fails.
	
	;Changing the font in a text style programmatically causes the issue so change
	;the arial font to something else (calibri) then back to Arial should trigger
	;the problem if the problem persists in the file.  This checks each style that
	;uses Arial font.

	(setq stylelist (ccGetStylesUsingFontWC "ARIAL.*")) ; the period excludes all Arial family fonts like Bold, Italics, etc.
	(foreach style stylelist
		(princ (strcat "\nProcessing Style: " style))
		;(setq style (nth 2 stylelist))
		;(setq style "carducci-std")
		(command "-style" style "calibri.ttf" "" "" "" "" "");Change style to use some other font.
		(command "-style" style "arial.ttf"   "" "" "" "" "");Then change the font back to Arial...that fixes the problem
		
		;test to see if fix was successful

		(if (setq e (assoc -3 (entget e (list "ACAD"))))
			;The fontName will have a name extension like "Arial TUR" if there is a codepage problem
			(setq fontName (cdr (assoc 1000 (cdr (car (cdr e))))))
		)
		(if (= fontName "Arial")
			(princ "...All good.")
			(progn 
				(alert "Arial TUR fix failed.  Restart session before proceeding with any scripts that change fonts")
				(setq rtn nil)
			)
		)
	)
	rtn
)

To clean a project care must be taken to work your way up the xref chain since a corrupt file can corrupt the parent xref (and the session) causing the need to constantly restart the session during a script.

 

James


This xref infection sounds very similar to the regapp issue too. 😔

0 Likes
Message 14 of 18

ronjonp
Mentor
Mentor

I had some time to dig into the problem this morning and this code seems to fix the mess. I'll be testing this more and will report if any unwanted side effects are noticed.

(defun c:fixarial (/ a e)
  ;; RJP » 2019-02-20
  ;; Fixes styles that reference arial font and are set to a different code page
  ;; Use at your own risk
  (vlax-for x (vla-get-textstyles (vla-get-activedocument (vlax-get-acad-object)))
    (cond ((and	(= "ARIAL" (strcase (vl-filename-base (vla-get-fontfile x))))
		(setq e (entget (vlax-vla-object->ename x) '("ACAD")))
		(/= "ARIAL" (setq a (strcase (cdadar (cdr (assoc -3 e))))))
	   )
	   (vla-setfont x "Arial" :vlax-false :vlax-false 0 34)
	   (print (strcat "Text style '" (vla-get-name x) "' referencing '" a "' fixed..."))
	  )
    )
  )
  (princ)
)
(vl-load-com)
Message 15 of 18

CADdaddy.com
Collaborator
Collaborator

Hi all again,

 

In my last post I stated that I had found that my test drawing no longer had this issue after I audit the drawing.  While that was true, I later encounted another drawing that is NOT fixed by audit.  I've attached that DWG file for any interested testers.  I've simplified the drawing by  exploding the blocks and purging and deleting some texts referring the the client and project.  I've also improved my test/fix program that now tests the font in EVERY style.

 

Here is the output after processing the attached drawing file.  Notice that it processes (and PASSES)  some styles that use Arial before before it finally encounters the style named "SHR" where it FAILS and corrupts the rest of the session.

Command: (LOAD "C:/Users/James/Desktop/Arial Tur/testArialTur.lsp")
Processing Style/Font: Standard/txt.shx PASS.
Processing Style/Font: H80/arial.ttf PASS.
Processing Style/Font: SIMPLEX/simplex.shx PASS.
Processing Style/Font: L100/simplex.shx PASS.
Processing Style/Font: PRELIM/arial.ttf PASS.
Processing Style/Font: L100-001x/simplex.shx PASS.
Processing Style/Font: L240-001x/simplex.shx PASS.
Processing Style/Font: LINE/simplex.shx PASS.
Processing Style/Font: L100-030X/simplex.shx PASS.
Processing Style/Font: L80/simplex.shx PASS.
Processing Style/Font: L120/simplex.shx PASS.
Processing Style/Font: L200/simplex.shx PASS.
Processing Style/Font: HELV/arial.ttf PASS.
Processing Style/Font: L060/simplex.shx PASS.
Processing Style/Font: L080/simplex.shx PASS.
Processing Style/Font: M200/monos.ttf PASS.
Processing Style/Font: SHR/arial.ttf FAIL. Session is corrupt.
Processing Style/Font: M100/monos.ttf FAIL. Session is corrupt.
Processing Style/Font: STAMP/romand.shx FAIL. Session is corrupt.
Processing Style/Font: L060-100X/simplex.shx FAIL. Session is corrupt.
Processing Style/Font: MtXpl_Courier_New/cour.ttf FAIL. Session is corrupt.
Processing Style/Font: MtXpl_Symbol/symbol.ttf FAIL. Session is corrupt.

Here is my updated test code:

(defun testFontInEveryStyle ( / elist style oldfont oldFontIsTTF Fail)
	;tests to see if, when Arial font is changed programatically, whether the
	;xdata displays "Arial" or something else based on language (like "Arial TUR")
	
	(defun ArialXdataIsCorrect (stylename / e xdata xDataFontname)
		;(ArialXdataIsCorrect "standard")
		;return t if OK, nil if unexpected result
		;get the contents of the xdata
		;(setq stylename "standard")
		(setq rslt t e (tblobjname "style" stylename))
		(if (setq xdata (assoc -3 (entget e (list "ACAD"))))
			(setq xDataFontname (cdr (assoc 1000 (cdr (car (cdr xdata))))))
		)
		(cond
			((not xdata) t) ;font is SHX
			((= xDataFontname "Arial") t) 
			(t nil)
		)
	)
	
	(defun isTrueType (styleName / )
		;(isTrueType "standard")
		(if (assoc -3 (entget (tblobjname "style" style) (list "ACAD"))) t nil)
	)
	
	(setvar "cmdecho" 0)
	;go through all styles and test
	(setq elist (tblnext "STYLE" T))
	(while elist
		(setq style (cdr (assoc 2 elist)))
		;only proccess non-xref styles
		(if (not (wcmatch style "*|*"))(progn
			(setq oldfont (cdr (assoc 3 elist)))
			(setq oldFontIsTTF (isTrueType style))
			(princ (strcat "\nProcessing Style/Font: " style "/" oldfont))
			;change font programatically
			(command "-style" style "calibri.ttf" "" "" "" "" "");Change style to use some other font.
			(command "-style" style "arial.ttf"   "" "" "" "" "");Change style to Arial
			(if (ArialXdataIsCorrect style)
				(princ " PASS.")
				(progn  (princ " FAIL. Session is corrupt.")(setq Fail t))
			)
			;change font back to old font after test.  Detect type of old font
			;because SHX command responses are different than TTF
			(if oldFontIsTTF
				(command "-style" style oldfont   "" "" "" "" "")
				(command "-style" style oldfont   "" "" "" "" "" "")
			)
		))
		(setq elist (tblnext "STYLE" nil))
	)
	(if Fail (alert "FAIL. Session is corrupt."))
	(princ "\nDone.")(princ)
)
0 Likes
Message 16 of 18

ronjonp
Mentor
Mentor
Accepted solution

Did you ever give this a try? Works well for me so far.

I could not get your method of switching fonts then switching back to work for me?

 

(defun c:fixarial (/ a e)
  ;; RJP » 2019-02-20
  ;; Fixes styles that reference arial font and are set to a different code page
  ;; Use at your own risk
  (vlax-for x (vla-get-textstyles (vla-get-activedocument (vlax-get-acad-object)))
    (cond ((and	(= "ARIAL" (strcase (vl-filename-base (vla-get-fontfile x))))
		(setq e (entget (vlax-vla-object->ename x) '("ACAD")))
		(cdadar (cdr (assoc -3 e)))
		(/= "ARIAL" (setq a (strcase (cdadar (cdr (assoc -3 e))))))
	   )
	   (vla-setfont x "Arial" :vlax-false :vlax-false 0 34)
	   (print (strcat "Text style '" (vla-get-name x) "' referencing '" a "' fixed..."))
	  )
    )
  )
  (princ)
)
(vl-load-com)

 

 

Message 17 of 18

CADdaddy.com
Collaborator
Collaborator

I think this works!  I could have sworn when I tested this last week the test failed.  Maybe my session was already corrupted when I did the test.

 

The best thing about this fix is that I can run this fix on my test dwg without corrupting the session.  Game changer!  Thank you VERY much!

 

James

0 Likes
Message 18 of 18

ronjonp
Mentor
Mentor

@CADdaddy.com wrote:

I think this works!  I could have sworn when I tested this last week the test failed.  Maybe my session was already corrupted when I did the test.

 

The best thing about this fix is that I can run this fix on my test dwg without corrupting the session.  Game changer!  Thank you VERY much!

 

James


Glad this helps you out 🙂 It's helped me quite a bit too!

0 Likes