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



Attachment: file1_normal_kui0.swf
Description: Binary data

Attachment: file2_kui0.movie.xml
Description: Binary data

Attachment: file3_angular_kui0.swf
Description: Binary data

<<attachment: pic31628.jpg>>

Attachment: file4_patch1.txt
Description: Binary data

Attachment: file5_messages.txt
Description: Binary data

Attachment: file6_patch2.txt
Description: Binary data

_______________________________________________
swfmill mailing list
swfmill@osflash.org
http://osflash.org/mailman/listinfo/swfmill_osflash.org

Reply via email to