In spite of being a relatively fresh project, the Shumway does surprisingly well in rendering .swf files created with Adobe Flash.
However, one can also create .swf from a .pdf or even a .ppt using one of the various converters. The output of these, however, tend to contain simpler objects, like labels, and the processing of such files is not quintessential to shumway core developers.
LettersFlash is a true hipster plugin: it could use its own fonts before it was cool. It was easy, as .swf files include vector objects, and fonts are exactly that in a binary form. A font embedded into an .swf file contains the character codes and the accompanying glyphs as well. The flash player needs an index (a byte offset), too, which determines the mapping of the shapes in the binary .swf file .
When Shumway meets a chunk that describes a font while reading the .swf file, it creates an opentype font from the shapes and character codes found therein and loads it into the browser through a data url, thus we can draw on our canvas using the font in question.
The problem arose when the fonts embedded into certain swf files seemed to contain noise only. Upon further inspection, it turned out that Shumway did not use the index and read a minimum of 2 bytes. In such broken files, the font contained a 1-byte “letter” that Shumway failed to handle, hence the slip in processing. After the discovery of the error, troubleshooting was straightforward: the program must follow the index and skip 1-byte letters.
The next problem we had to face was that an opentype and an swf-embedded font do not share the same origo. Consequently, when displayed in Windows, the letters appeared upside down and slipped outside the assigned field. This was easy to eliminate: y coordinates had to be reflected.
TextsWhen letter rendering was cleared, we moved on to text rendering. Here, we found surprisingly few errors, but the original rendering relied on upside down letter rendering - due to the now fixed origo issue. This was easy to cure with the transformation of text rendering: the translateY parameter had to be inverted.
ResultBelow are the animgifs of troubleshooting stages:
Note the difference in letter rendering: OS X is quite forbearing in terms of font errors, while Windows adheres to the OpenType standards.