yang686526

different vectorization of same file on windows and mac
different vectorization of same file on windows and mac
hi,
i am using dwgdirect libs 1.14.05 for windows (vc8 built) and mac (xcode built).
attached is a simple file with an mtext entity. i call zoomextents() and set up the vectorizer with a call to onsize() with the same rect on both platforms (say {0, 0, 100, 100}, it doesn't matter).
on windows, findfile() is called only once for "txt".
on mac, findfile() is called thrice. firstly for "txt", then twice for "simplex.shx".
i make sure that findfile() returns valid paths to both txt.shx and simplex.shx.
i get two calls to textproc(). on windows i get the msg parameter as:
"this is a small text box "
and
"using arial font"
and on mac i get:
"this is a small text "
and
"box using arial font"
the values of u and v vectors received are also slightly different. all in all, leading to very different rendering on different platforms.
can anyone point out what i am doing wrong? or is this a bug?
attached files
on windows the text is rendered using arial.ttf. findfile() is not called for font installed on windows.
on mac simplex.shx is substituted.
do you mean that findfile("arial.ttf") is not called on mac?
sergey slezkin
yes, findfile() is not called for arial.ttf on mac.
regards,
varun
last edited by varunsnair; 28th august 2006 at 06:13 amfff">.
hi sergey,
any progress on this?
regards,
varun
you need to supply an implementation of oddbhostappservices::ttffilenamebydescriptor for the mac. the default version (exhostappservices::ttffilenamebydescriptor) works only for windows.
the mtext contains only the typeface name arial, so this function is required to obtain a font file name that can be subsequently passed to findfile.

thanks neil.
providing the implementation of ttffilenamebydescriptor() does now break the mtext into the similar strings upon vectorization on both windows and mac.
however, am still facing the issue of different values of position, u and v vectors on different platform.
for the attached file, when i ask for vectorization after zoomextents(), by specifying a rectangle of {0, 0, 100, 100}, i get values:
for first text fragment ("this is a small text box "):
win (vc8):
position = {0.79179047134519465, 53.302789678405077, 0.00000000000000000}
u = {6.7633918329114584, 0.00000000000000000, 0.00000000000000000}
v = {0.11805544357844605, 6.7633918329114584, 0.00000000000000000}
mac (xcode):
position = {0.71155660911995255, 53.180408238600847, 0}
u = {6.5148744449774121, 0, 0}
v = {0.11371755643626623, 6.5148744449774121, 0}
why this is so?
regards,
varun
different results on windows and mac most likely mean that different fonts are used.
after you provided implementation of ttffilenamebydescriptor() is findfile() called with value returned by ttffilenamebydescriptor()?
btw, correct file name returned by ttffilenamebydescriptor() may be not arial.ttf but arialbd.ttf, arialbi.ttf etc. depending on bold, italic flags.
sergey slezkin
the findfile() call comes for both platform with "arial.ttf" only and the full path returned is also of this file only.
i've attached a screenshot showing the rendering on mac and windows. the area outlined in black is the rect we pass to zoomextents() ({0, 0, 300, 300} in this case). the windows one, looks a little bolder than the mac one as the font size calculated for the text on windows come out to be a little higher based on the values of the vectors passed into textproc().
our implementation of ttffilenamebydescriptor() currently only returns ".ttf" appended to the typeface name, which is wrong as you pointed out. however, for this particular case, as neither bold nor italic attributes are applied to the mtext, hence i think the problem lies somewhere else.
attached images (16.8 kb, 28 views)

regards,
varun
hi sergey,
after providing the correct implementation of ttffilenamebydescriptor(), we seem to have uncovered more issues.
on mac, the system fonts come in font suitcases. the problem is that they have the font data stored in their resource fork. worse, one suticase file can contain multiple fonts (uncommon) or multiple styles of font (more common case - arial regular, arial bold, arial italic, arial bold italic etc. all are bunched together in one suitcase file named arial).
when findfile() is called for a such a font, and returns the path to font suitcases, we get a exc_bad_access with the following stack:
code:
#0 0x24f8dd74 in odtruetypefont::descriptor at odstring.h:103
#1 0x24f8ecd4 in odtruetypefont::loadfile at odstring.h:103
#2 0x24fe9850 in odfonttable::createttf at odstring.h:103
#3 0x24fe99b4 in odfonttable::_getfont at odstring.h:103
#4 0x24fe9b00 in odfonttable::getfont at odstring.h:103
#5 0x250082f8 in oddbfontservices::loadstylerec at odstring.h:103
#6 0x24cf6f14 in odgitextstyle::loadstylerec at odstring.h:103
#7 0x24f50054 in odmtextiterator::changefont at odstring.h:103
#8 0x24f5454c in odmtextiterator:rocess at odstring.h:103
#9 0x24f562a0 in convertmtexttocodepage at odstring.h:103
#10 0x24ec25bc in oddbmtextimpl::converttosyscodepage at odstring.h:103
#11 0x24ebc454 in oddbmtextimpl::dwginfields at odstring.h:103
#12 0x24ec5084 in oddbmtext::dwginfields at odstring.h:103
#13 0x25357460 in performloading at staticrxobject.h:47
#14 0x24d82894 in oddwgfileloader::loadobject at odstring.h:103
#15 0x24d84b08 in oddwgfileloader::loadobject at odstring.h:103
#16 0x24d9eeb8 in oddwgr18fileloader::loadobject at odstring.h:103
#17 0x24d80b98 in odobjloadresolver::queryx at odstring.h:103
#18 0x24bc34e8 in oddbobjectid:penobject at odstring.h:103
#19 0x24d80cb8 in oddwgfileloader::enddbloading at odstring.h:103
#20 0x24b067b4 in oddbdatabase::closeinput at odstring.h:103
#21 0x24b08af8 in oddbdatabase::readfile at odstring.h:103
#22 0x24b093b4 in oddbhostappservices::readfile at odstring.h:103
#23 0x24ac7724 in exhostappservices::readfile at exhostappservices.cpp:127
things work fine when font file is a normal windows style ttf font file, except of course the difference in vectors passed to textproc() between windows and mac.
regards,
varun
last edited by varunsnair; 7th september 2006 at 01:32 amfff">.
also, is the support for fonts only limited to ttf and shx fonts?
on mac, i tried with a opentype font and the vectorizer produced different string fragments between when the opentype font file was found and when it was not found.
however, on windows, the presence/absense of otf file made no difference.
regards,
varun
hi sergey,
any more progress on these issues?
to summerize, the problems we face as of now are:
1. for a ttf font, our textproc() is called for the same mtext with different u and v vector values on windows and mac.
2. after providing correct implementation of ttffilenamebydescriptor(), on mac we experience a crash when the font file is resource fork based.
3. presence/absense of an otf file makes no difference in case of windows but alters the vectorization in a similar way as a ttf font, on mac.
thanks for taking the time out to investigate this.
regards,
varun
for ttf fonts on windows dd uses windows api to access installed fonts. and does not access .ttf files directly.
on other platforms dd uses freetype library to load .ttf files. where was a bug in dd which caused crash if freetype failed to load a font file. this is fixed for next release.
sergey slezkin
so as i understand it (referring to points from my last post):
slightly different values: is caused because on windows dd does not access the ttf file and on other platforms it does (via freetype). still in my view if the ttf file used on windows, is brought to mac, and we ensure that findfile() returns the reference to this file only, then the difference in values should not be there. but we found difference in values after doing this also. could you shed some more light on it as to why exactly this is happening?
crash on mac: will be fixed in the next dd release (the one after 2.0.3?). and the inability to work with font data in resource fork is a freetype bug on mac.
support for otf: is again because of use of freetype library on non-windows platform.
am i correct?
also was wondering, is there a way for the host application to provide font services to the dd library, much the same way as for raster services? this would be very useful for applications that provide support for custom font types or font types other than those supported by autocad (or freetype in this case). also since font data is cached by most applications, in my view this would result in a performance improvement also.
regards,
varun
1. dwgdirect doen't use font file directly under windows and uses windows api. it seems widows api and free type interpret font file data by different way slightly. so we get slightly different font glyph data (size symbols). these difference are in case tree type is used under windows also.
2. we have fixed this bug.
3. could you send by mail (or attach) your .oft font. we will try to investigate this problem. tree type supports such files ( at least there is mention in documentation ).
best regards,
sergey z.
so if you use freetype on windows also, still for the same file and same font file, different values are generated on windows and mac? if so, then looks like a bug in freetype library. can you guys escalate it to them?
thanks. eagerly awaiting the next release. any eta on that?
i can't upload the fonts, but the problem is easily explained:
on windows dd uses windows api using the typeface name. if that font is a otf font that windows can locate, then the rendering will be correct, irrespective of the fact whether or not ttffilenamebydescriptor() was able to locate the file or not.
on mac however, since freetype will solely depend on the value returned by ttffilenamebydescriptor(), us being not able to locate the font will lead to wrong vectorization of text.
this leads to an incosistency between the two platforms, i.e. vectorization is always proper on windows, but is proper on mac only when our implementation of ttffilenamebydescriptor() is able to find the font file.
regards,
varun