swftools-common
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Swftools-common] Problem with color gradient in PDF2SWF


From: Andreas Haufler (scireum GmbH)
Subject: Re: [Swftools-common] Problem with color gradient in PDF2SWF
Date: Sat, 9 Oct 2010 17:28:58 +0200

Hey guys,

I digged into the code and did some debugging. However, my C skills are limited and I'm currently stuck on the following problem. 

The bars as shown in the SWF are single lines with a width of 9.92. Those stroked next to each other form the gradients in the background. Thing is, in the SWF (I ran swfdump) those lines are converted into shapes (rects):

[020]        43 DEFINESHAPE3 defines id 0013
                 | fillstyles(01)        linestyles(01)
                 | 1 ) SOLID 2056aeff    1 ) 0.00 00000000
                 |
                 | fill: 01/00 line:00 - moveTo 602.00 -12.40
                 | fill: 01/00 line:00 - lineTo 602.00 857.15
                 | fill: 01/00 line:00 - lineTo 611.85 857.15
                 | fill: 01/00 line:00 - lineTo 611.85 -12.40
                 | fill: 01/00 line:00 - lineTo 602.00 -12.40
                 |
[01a]         5 PLACEOBJECT2 places id 0013 at depth 0010
[020]        43 DEFINESHAPE3 defines id 0014
                 | fillstyles(01)        linestyles(01)
                 | 1 ) SOLID 2157aeff    1 ) 0.00 00000000
                 |
                 | fill: 01/00 line:00 - moveTo 599.35 -12.40
                 | fill: 01/00 line:00 - lineTo 599.35 857.15
                 | fill: 01/00 line:00 - lineTo 609.35 857.15
                 | fill: 01/00 line:00 - lineTo 609.35 -12.40
                 | fill: 01/00 line:00 - lineTo 599.35 -12.40
                 |
[01a]         5 PLACEOBJECT2 places id 0014 at depth 0011

One can see there, that the x-coordinates do not match, which explains the white bars between the boxes.

So basically there are two possibilities: Either the width is wrong, or the x-positions are wrong. my guess is the width, since otherwise it would "add" up (probably) and the white bars would get wider. My main problem is, that I can't see where the DEFINESHAE3 is generated. My trace ends here:

(Line numbers might not be super accurate, since my clone is not up to date....git pull doesn't like me somehow...):
17 swf_ShapeSetLine() /home/test/workspace/pdf2swf/lib/modules/swfshape.c:462 0x0816943a
16 linetoxy() /home/test/workspace/pdf2swf/lib/devices/swf.c:416 0x0813910a
15 lineto() /home/test/workspace/pdf2swf/lib/devices/swf.c:440 0x081391e1
14 drawgfxline() /home/test/workspace/pdf2swf/lib/devices/swf.c:1758 0x0813deb0
13 swf_stroke() /home/test/workspace/pdf2swf/lib/devices/swf.c:2578 0x08141880
12 GFXOutputDev::strokeGfxline() /home/test/workspace/pdf2swf/lib/pdf/GFXOutputDev.cc:1206 0x08059ea4
11 GFXOutputDev::stroke() /home/test/workspace/pdf2swf/lib/pdf/GFXOutputDev.cc:2499 0x0805df85
10 Gfx::opStroke() /home/test/workspace/pdf2swf/lib/pdf/xpdf/Gfx.cc:1418 0x080e10d9
9 Gfx::execOp() /home/test/workspace/pdf2swf/lib/pdf/xpdf/Gfx.cc:696 0x080dcd3f
8 Gfx::go() /home/test/workspace/pdf2swf/lib/pdf/xpdf/Gfx.cc:587 0x080dcec1
7 Gfx::display() /home/test/workspace/pdf2swf/lib/pdf/xpdf/Gfx.cc:559 0x080dd337
6 Page::displaySlice() /home/test/workspace/pdf2swf/lib/pdf/xpdf/Page.cc:317 0x080c7881
5 Page::display() /home/test/workspace/pdf2swf/lib/pdf/xpdf/Page.cc:266 0x080c7b71
4 PDFDoc::displayPage() /home/test/workspace/pdf2swf/lib/pdf/xpdf/PDFDoc.cc:319 0x0808af6f
3 render2() /home/test/workspace/pdf2swf/lib/pdf/pdf.cc:192 0x0806e10c
2 pdfpage_rendersection() /home/test/workspace/pdf2swf/lib/pdf/pdf.cc:220 0x0806e2f7
1 main() /home/test/workspace/pdf2swf/src/pdf2swf.c:803 0x0805256c

However, as far as I can tell, this only emits one line and this is also only called one....If one has any insight into this, I'll be happy to hear :-)

Enjoy your weekend...

freundliche Grüße
scireum GmbH

Andreas Haufler
Geschäftsführer

-------------------------------------------------------------------------------------------------------
scireum GmbH, Uferstr. 18, 73630 Remshalden

Tel.: (07151) 20637 21 - E-Mail:  address@hidden
Fax: (07151) 20637 19 - Internet: http://www.scireum.de

Geschäftsführer: Michael Haufler, Andreas Haufler
Amtsgericht Stuttgart, HRB 732171


2010/10/8 Chris <address@hidden>
On Fri, 8 Oct 2010 16:02:38 +0200
"Michael Haufler (scireum GmbH)" <address@hidden> wrote:

> The really problem is that pdf2swf don't tell us about its behaviour. (The
> catalog has about 1200 Pages and only 8 Pages have this problem)
> So one way is to convert the whole catalog with -O2 but that would be
> suboptimal.

Unfortunately, calling pdf2swf in the manner of a function won't do you
a lot of good!

> The other way is to do those 8 Pages manually which is also not desirable
> cause we have quite a few of those candidates ;-)
>
> Has anyone any idea?

I can manage a few off the cuff suggestions ( see below ). I'll leave you
judge how helpful..

> Here is what pdf2swf tells us (I also tried -v but the there is no
> additional info)

More than one 'v' will up the verbosity level, try -vv or -vvv

Adding -I will do a dummy run, showing you what is happening.

> D:\>pdf2swf xxx.pdf
> NOTICE  Output filename not given. Writing to xxx.swf

Oh dear. The 'D:\' indicates a version of Windows. :o(  How are you at scripting
in it, or in a language running under it?

Only thing I can think of,

 - a dummy run with the appropriate verbose level to pick up and log the 'error'
  page numbers

 -  have two different versions of the pdf2swf command string on an branch; the
   'good' page sequence goes to one, the 'bad' to another. Use -p [ranges]

 - cement the swfs back together with swfcombine.

Best I can come up with. A bit of work undoubtedly, but possible.


Regards,



Chris.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]