Some SWF shapes are not rendered in PDF about swf-convert

[arkbene]

Just checked: the problem exists for v. 0.0.1 as well. So, it definitely is not a result of Jindra's fix.

[arkbene]

Apparently, the problem exists for vertical thin lines as well. They also disappear with clipping on. With clipping off this is what you get:

(this is heavily zoomed in). So, it is likely that the line is 1 unit-of-length thick, and it's just being drawn by exactly 1 unit of length off. That's why it's being clipped off. So, the problem is likely not with the clipping algo but with the algo that draws shapes.

I am not sure, but this may be something as simple as rounding down instead of up somewhere.

[maltaisn]

I think the matrix Y scale component may be inverted for some reason. If I try outputting SVG the same issue appears. I get:

<path d="M0 0V11900H8400V0H0" fill="#fff"/><g clip-path="url(#A)"><image xlink:href="images/0.png" transform="matrix(5614 0 0-10 1305 949)"/></g><defs><clipPath id="A"><path d="M1315 959H6930V949H1315v10"/></clipPath></defs></svg>

If I change the matrix to matrix(5614 0 0 10 1305 949)" (notice the missing minus sign) it seems fine. Can you try to do the same with the vertical line? Or send me the file.

The matrix being wrong would be pretty weird since its values come directly from the file. But judging by the picture you shared it seems it's not the clipping path that's wrong, but the image placement. There's also -DdrawClipBounds that might help here.

[arkbene]

Can you try to do the same with the vertical line? Or send me the file. — Give me a minute, please)

[arkbene]

bug2.swf.zip

-- the example not exactly minimal, but should be clear enough for the purpose of illustrating the issue.

bug2.pdf

-- what I get with clipping turned OFF. With clipping On I get errors, due probably to the fact that the SWF file was edited (for this demonstration) by a person with zero knowledge of the SWF format (me).

Anyhow, the SWF file shows fine in my SWF player (Elmedia) -- All horizontal arrows are aligned, all vertical ones (with a slight exception of the left-most ones) are aligned as well. The situation is different in PDF, though, as I showed above.

[maltaisn]

I think you're right, it has something to do with an offset. There's the same offset for every arrow.

The green is the clip path. Here you actually have a 1x1 black image that's getting stretched by a matrix transform to be 353x10. The required offset is (+10,+10). I just can't wrap my head around yet on how to fix it in a way that makes sense and doesn't break anything else.

Out of curiosity, have you tried other viewers? Does it look fine? Jpexs internal viewer fails for me for example.

[arkbene]

Jpexs internal viewer fails for me for example — I can see some of the arrows some of the time with it.

Here's what I've been able to figure out in the meantime:

1. We have 3 types of entities: the lines, the clip paths (for the lines) and everything else (in the examples I sent "everything else" is just the arrow heads, taken from a font; but this is because the file has been cleaned up by me; originally, there's a bunch of text, but the problem appears only for these lines/their clip paths);
2. The clip paths are in the right positions relative to "everything else", it seams;
3. The lines are off by (-10, -10) relative to "everything else" AND the clip paths.

Here we already have 2 possibilities:

a) the lines are off by (-10, -10); clip paths and everything else are fine;
b) everything else and clip paths are both off by (+10,+10).

b) would be really weird, especially given that 10 is exactly the width of the line; so it's definitely a)

So, the question is: why would a line be drawn off by (-10,-10)? Actually, there two questions:

1. Why doesn't the algo just use the same shape for the line itself and its clip path? Wait, what do I mean by that? The clip path must be already part of the SWF, right? No, it's not! In fact, the so-called clip depth is not set for any of the lines!

And so it must be that the clip paths are generated (!) by swf-convert; and this leads me to question 2) which is, actually, a rephrasing of 1):

2. Why does the algo generate any clip paths for these lines at all and, even if it does, why won't it just copy the (correct) parameters of those clip paths to the parameters of the lines?

[arkbene]

How about that!

This is a bitmap defined in DefineBitsLossless, then used by DefineShape, which is then used by PlaceObject2.

-DdisableClipping -DdebugLineWidth=1 -DdrawShapeBounds

(btw, -DdrawTextBounds draws nothing for the bitmap, as well as for the lines -- is that normal?)

I will try to prepare the SWF to show this behaviour soon.

[arkbene]

bug3-bitmap.swf.zip

The bitmap bug example, as promised.

Here, 2351 is the white canvas rectangle, 2399 is the shape with the 2398 bitmap inside.

bug3-bitmap-with clipping.pdf

--- This was produced with -DdebugLineWidth=1 -DdrawShapeBounds

bug3-bitmap-DdisableClipping.pdf

--- This was produced with -DdisableClipping -DdebugLineWidth=1 -DdrawShapeBounds

Same (-10,-10) offset! Here, apparently, it knows nothing of the width of the lines since there are no lines. So, there's some const == 10 points hard-coded in the algo somewhere (I've learnt by now that 1 point in SWF is 1/72/20 = 1/1440th of an inch, must be some natural unit for SWF).

Sorry for being verbose, but it's for a reason: I know zero Java, so all I can do is test and talk)

[arkbene]

bug3-bitmap.svg.zip

--- This is the SVG (as obtained by svg bug3-bitmap.swf -o bug3-bitmap.svg). No more minus signs! -- They, as it turns out, had nothing to do with the problem. But note the all too obvious offset between the clip path and the bitmap matrix: ClipPath's upper-left corner = (5376, 2871) vs Bitmap's upper-left corner = (5366, 2861).

[arkbene]

Here's something else which might be useful:

1. the 0.png image can be inspected to see that its width x height is 53 x 51 pixels. I double-checked: JPEXS shows exact same dimensions of the bitmap inside the SWF.
2. Observe the image transform matrix in the SVG code screenshot in my previous post:

matrix(2.34 0 0 2.39 5366 2861)

with the increased precision options (--transform-precision 5 --precision 5 --percent-precision 5) we get:

matrix(2.39622 0 0 2.39215 5366 2861)

Now, how do we get these two scale factors, 2.39622 & 2.39215?

Note the "h126v122" part in the clip path in the above SVG screenshot. These are two relative displacement drawing commands. Assuming that all pixels that are touched in drawing are part if the clip (i.e., assuming that all such pixels should get fully drawn), the width of the drawn area is 126 + 1 by 122 + 1 points. This gives the scaling factors for the matrix:

a = 127 / 53 = 2.39622641509433962264
d = 123 / 51 = 2.41176470588235294117

Oops! The first number matches exactly, while the second one is off.

Let's guess: maybe the algo forgets to add +1 to the 122?

d = 122 / 51 = 2.39215686274509803921

A perfect match! And another bug in the algo that was just found!

So, it turns out that right now, even if you find a way to fix the (-10,-10) bug, the lowest row of pixels in every bitmap will still be partially clipped off. So, this will need to be fixed as well.

Sorry, guys, for giving you more headache)

UPDATED:

1. Of course, the way the scaling factors are calculated there will be space left at the bottom rather than pixels being clipped off. My mistake.
2. I checked the SWF and the DefineShape specifies the size of the image top EXACTLY 126 x 122 twips. So, I guess, the algo should obey this, and this means the scaling factors should be exactly 126/53 and 122/51. So, in fact, the second factor seems correct while the first one (x-dir) is currently overly cautious. And this also means that the clip path is currently 1 twip too wide in both x- and y- directions!

[maltaisn]

The line is made of a shape with a bitmap fill. The shape has a path, and the bitmap fill has a matrix. There's no line here per se, just a stretched bitmap.

Why does the algo generate any clip paths for these lines at all and, even if it does, why won't it just copy the (correct) parameters of those clip paths to the parameters of the lines?

The clip is part of the SWF. The bitmap fill type is 0x41, i.e., "clipped bitmap".
As for the parameters, there's basically no conversion being made anywhere here because the image is 1x1 pixels. For the first bug SWF shows the following parameters for the horizontal line shape:

The same parameters can be found in the SVG:

transform="matrix(5614 0 0-10 1305 949)"

We know the path is correct since the debug shape bounds is correct. The matrix is taken as is, so that's not the issue.

Oops! The first number matches exactly, while the second one is off. Let's guess: maybe the algo forgets to add +1 to the 122?

Again there's not many transformations being done here. The bitmap matrix in SWF is [[2.39622, 0.0, 5366], [0.0, 2.39215 2861]]. If we multiply the scaling components by the image dimensions (53x51) to get the actual image size, we get the matrix [[127, 0.0, 5366], [0.0, 122, 2861]]. But the shape path draws a 126x122 square, not 127x122! There's no bug in the path parser, jpexs confirms that it's really that:

(btw, -DdrawTextBounds draws nothing for the bitmap, as well as for the lines -- is that normal?)

It's a bitmap, not a text, so nothing is drawn. -DdrawTextBounds is for DefineText objects.

---

Adding a fixed (+10,+10) offset to all image matrices seems to fix all your issues. On my side, it seems to fix one particular case where an image was misaligned, but it also breaks other cases that used to work fine. Now where is the bug?

• The SWF viewer. I suppose that's unlikely, but then why is it showing correctly there?
• swf-convert, which basically takes the SWF data and spits it out as-is, no transformations done. Unless there's some obscure SWF flag which results in a (+10,+10) offset, and the viewer is handling it, but not swf-convert.
• Whatever tool used to create the SWF creates bitmap with wrong matrices. swftools has some bugs I had to sidestep so this is definitely a possibility.

I can add a -DbitmapMatrixTranslate=[x,y] option if adding the offset fixes it for you.

[arkbene]

Thanks for another prompt reply!

I am looking into bug.swf again, now armed with the "Raw edit" option for the DefineShape, which I discovered in JPEXS thanks to your screenshot) And also am reading Adobe Flash manual trying to figure out why 367919103 = 5614)

I also found the option to export to XML very helpful.

Among the things that I am seeing already: indeed, the SWF file contains both the shapeBounds rect and the bitmapMatrix, and their corresponding offsets differ by (10,10). So, there's definitely a problem with the SWF file itself. Why SWF players (at least some) are showing the shapes that should be clipped, is another matter. I'm going to spend some time later testing this on as many players as I can get installed on my system.

"I can add a -DbitmapMatrixTranslate=[x,y] option if adding the offset fixes it for you." -- It will indeed be very helpful in the meantime. Thanks!

[maltaisn]

Here's a release: swf-convert.zip

With the option -DbitmapMatrixOffset=[<x>,<y>], you can use 10,10.

[arkbene]

Thanks a lot!)

[arkbene]

It's a bitmap, not a text, so nothing is drawn. -DdrawTextBounds is for DefineText objects.

I see. However, -DdrawClipBounds doesn't do much drawing either, in what I tested.

[arkbene]

I'm going to spend some time later testing this on as many players as I can get installed on my system.

Tested the three uploaded bugN.swf files with the Adobe Flash projector (yes, I have just learnt about its existence). The horizontal line is perfectly visible, the arrows are perfect. On the other hand, the bug3-bitmap.swf is shown with the top of "R" clipped off.

Curiouser and curiouser ...

My guess: there has always been this bug in the Adobe products. Whoever produced these SWFs tried to compensate for the bug by introducing the offset. However, the introduction of the offset lead to some of the bitmaps being clipped off (i.e., the bug didn't manifest itself on these bitmaps originally, and so the compensation was not needed), which went unnoticed by the producer.

The next step would be to try to see what happens if we fix (align the shapes with clip paths) in the SWF (should be easily done in JPEXS by exportXML-->fix->importXML) and then play the fixed SWF in the projector.