[swfmill] Some glyphs from MSGOTHIC.ttc reshaped "angular"
matsuhashi@quick.co.jp
matsuhashi at quick.co.jp
Fri Dec 8 02:39:31 EST 2006
Hello, List.
I am using
swfmill-0.2.11
Windows 2000
Cygwin+gcc.
I found a lot of glyphs of MSGOTHIC.TTC imported into swf by swfmill-0.2.11
is slightly (wrongly) reshaped: A curve is turned into a pair of straigh
lines, forming an angle.
Let me show you an example. The attached file1 is produced with Macromedia
Flash MX2004 showing 2 Japanese characters ( pronounce [ku] and [i]) and
numeric "0" (zero).
The file1 is fine, has no problem.
(See attached file: file1_normal_kui0.swf)
I made a <movie> XML instance "file2" :
(See attached file: file2_kui0.movie.xml)
I processed this xml to get the following swf output.
(See attached file: file3_angular_kui0.swf)(Embedded image moved to file:
pic31628.jpg)
Please compare file1 and file3. Then you would easily see what I decribe
"reshaped angluar". Carefull eye will see a curve is turned into a pair of
straight lines forming an angle which the font designer obviously had not
intended.
This is a significant problem of swfmill for me; and for possible users in
Windows ja-JP environment, because the MSGOTHIC.TTC font is so wide-spread
and heavily used. The badness of imported font shapes is easily noticable.
I am afraid this problem may make Windows ja-JP users away from the
swfmill. I wanted to use swfmill for my business application, therefore I
investigated the reason of this phenomenon.
I read the source code file "swft_import_ttf.cpp" where I got a doubt.
@@ -221,10 +221,13 @@
for( int p = start; p<=end; p++ ) {
control = !(outline->tags[p] & 0x01);
cubic = outline->tags[p] & 0x02;
if( p==start ) {
+ if (control) {
+ fprintf(stderr,"outline starting with a control
point; glyph &#%i; of %s .\n", character, filename);
+ }
shaper.setup( outline->points[p-n].x, outline->points[p-n].y );
}
if( !control && n > 0 ) {
importGlyphPoints( &(outline->points[(p-n)+1]), n-1, shaper,
cubic );
(See attached file: file4_patch1.txt)
The original code is calling shaper.setup( ) if if( p==start).
This implies the orginal code assumes that the 1st point of glyph outline
is a "on the curve" point, not a "off the curve" point (control point, in
other words).
But is it OK? I doubt it.
I inserted a fprint statement which will be invoked if it encounters a
starting point which is "off the curve". I tried this modified version to
process the above mentioned file2. I got following messages.
[swfmill] outline starting with a control point; glyph 48 (0) of
C:\WINNT\Fonts\MSGOTHIC.TTC .
[swfmill] outline starting with a control point; glyph 48 (0) of
C:\WINNT\Fonts\MSGOTHIC.TTC .
[swfmill] outline starting with a control point; glyph 12356 (D) of
C:\WINNT\Fonts\MSGOTHIC.TTC .
[swfmill] outline starting with a control point; glyph 12356 (D) of
C:\WINNT\Fonts\MSGOTHIC.TTC .
[swfmill] outline starting with a control point; glyph 12463 (ッ) of
C:\WINNT\Fonts\MSGOTHIC.TTC .
(See attached file: file5_messages.txt)
This proves that there exists TrueType glyphs of which outline starts with
"off the curve" point. Sadness for Windows ja-JP users is that the MSGOTHIC
has plenty.
If swfmill does not like "off the curve" point to come at the start, then
how about moving it to the end of the outline points array? I thought. I
made the following patch.
bool control, cubic;
int n;
for( int contour = 0; contour < outline->n_contours; contour++
) {
end = outline->contours[contour];
n=0;
+ /*
+ * If the outline starting point is "off the curve",
reorder the points array.
+ * Shift the starting point off and move it the end of
outline points.
+ */
+ control = !(outline->tags[start] & 0x01);
+ if (control) {
+ FT_Vector pointsBuffer[(end+1)-start];
+ char tagsBuffer[(end+1)-start];
+ int i,j;
+ for (i=0, j=start; j<=end; i++, j++ ) {
+ // save the original points to temporary area
+ pointsBuffer[i].x = outline->points[j].x;
+ pointsBuffer[i].y = outline->points[j].y;
+ tagsBuffer[i] = outline->tags[j];
+ }
+ for (i=0, j=start; j<=end; i++, j++ ) {
+ if (i==0) {
+ // move the original starting point to the tail
+ outline->points[end].x = pointsBuffer[0].x;
+ outline->points[end].y = pointsBuffer[0].y;
+ outline->tags[end] = tagsBuffer[0];
+ } else {
+ // just shift the other points
+ outline->points[j-1].x = pointsBuffer[i].x;
+ outline->points[j-1].y = pointsBuffer[i].y;
+ outline->tags[j-1] = tagsBuffer[i];
+ }
+ }
+ }
for( int p = start; p<=end; p++ ) {
control = !(outline->tags[p] & 0x01);
cubic = outline->tags[p] & 0x02;
(See attached file: file6_patch2.txt)
Ah! this worked for me.
I hope this patch is considerd for the next revision of the swfmill
somethime.
MATSUHASHI,kazuaki
QUICK Corp, Japan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file1_normal_kui0.swf
Type: application/octet-stream
Size: 389 bytes
Desc: not available
Url : http://osflash.org/pipermail/swfmill_osflash.org/attachments/20061208/8b716d4a/ISO-2022-JPBZmlsZTFfbm9ybWFsX2t1aTAuc3dm-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file2_kui0.movie.xml
Type: application/octet-stream
Size: 501 bytes
Desc: not available
Url : http://osflash.org/pipermail/swfmill_osflash.org/attachments/20061208/8b716d4a/ISO-2022-JPBZmlsZTJfa3VpMC5tb3ZpZS54bWw-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file3_angular_kui0.swf
Type: application/octet-stream
Size: 396 bytes
Desc: not available
Url : http://osflash.org/pipermail/swfmill_osflash.org/attachments/20061208/8b716d4a/ISO-2022-JPBZmlsZTNfYW5ndWxhcl9rdWkwLnN3Zg-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic31628.jpg
Type: image/jpeg
Size: 15894 bytes
Desc: not available
Url : http://osflash.org/pipermail/swfmill_osflash.org/attachments/20061208/8b716d4a/pic31628-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file4_patch1.txt
Type: application/octet-stream
Size: 742 bytes
Desc: not available
Url : http://osflash.org/pipermail/swfmill_osflash.org/attachments/20061208/8b716d4a/ISO-2022-JPBZmlsZTRfcGF0Y2gxLnR4dA-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file5_messages.txt
Type: application/octet-stream
Size: 1223 bytes
Desc: not available
Url : http://osflash.org/pipermail/swfmill_osflash.org/attachments/20061208/8b716d4a/ISO-2022-JPBZmlsZTVfbWVzc2FnZXMudHh0-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file6_patch2.txt
Type: application/octet-stream
Size: 2023 bytes
Desc: not available
Url : http://osflash.org/pipermail/swfmill_osflash.org/attachments/20061208/8b716d4a/ISO-2022-JPBZmlsZTZfcGF0Y2gyLnR4dA-0001.obj
More information about the swfmill
mailing list