Description of problem:
Although the manual page for spumux (included in the dvdauthor package) states
that it should support bitmap subtitle files in both png or bmp format, current
release seems to have been compiled to support png only. This is a bit of a
problem, since ProjectX (one of the few linux video cutting tools with working
subtitle support) only produces bmp bitmaps from dvb recordings.
Version-Release number of selected component (if applicable):
Giving spumux a xml file containing references to bmp files gives the errors:
ERR: File videofile_st00000p1.bmp isn't a png
WARN: Bad image, skipping line -1
Earlier releases (at least in fc5) did have bmp support included in spumux.
BMP support would IIRC require compiling with ImageMagick, but ImageMagick pulls
in an untolerable amount of dependencies through librsvg2, that's why it's not
done by default in dvdauthor. See bug 212478.
Until the ImageMagick/librsvg2 dependency bloat problem has been fixed,
dvdauthor can be locally rebuilt with ImageMagick support with "rpmbuild
--rebuild --with imagemagick dvdauthor*src.rpm"
By the way, I would guess that it'd be pretty much trivial to make ProjectX
output PNG's instead of BMP's - built-in PNG support is included in all
semi-modern JRE's I'm aware of, and I think PNG is more of a standard than BMP
which (if correct) would make it a better choice.
Created attachment 157709 [details]
son2xml perl version
I can see why you'd want to skip this huge dependency chain, but unfortunately
the local rebuild solution you give does not seem to alter spumux behavior in
this respect. Maybe also some other flags are required?
ProjectX seems to currently be a more or less dead project -- the software is
available and works fine, but I wouldn't hold my breath expecting any further
As an interim measure, I've changed son2xml (a helper script used convert the
subtitle description file format) to do the conversion externally using optipng.
Hm, curious, could you post the output of "rpm -qRp /path/to/dvdauthor*rpm" for
the binary packages you rebuilt using "--with imagemagick"? If it was
successfully built with it, things like libMagick.so.* and libWand.so.* should
be listed. I just did a test build on F7 x86_64 using --with imagemagick, and:
$ rpm -qRp dvdauthor-0.6.14-1.cmn7.x86_64.rpm | grep 'lib[WM]'
Quickly peeking at the source, this seems to imply that HAVE_MAGICK was defined
during configure, and the code that emits the error in your initial comment
shouldn't have even been compiled in... maybe a dumb question, but you did
remember to actually install the binary packages rebuilt --with imagemagick, right?
You of course are correct, I suspect I had both the i386 and the x86_64 version
(with different compile options) installed at the same time which caused no end
of confusion on my part.
0.6.14-5 is currently being built with GraphicsMagick support. GraphicsMagick
has considerably fewer dependencies than ImageMagick in the first place, and
after today's fixes in Rawhide, even fewer; quite acceptable anyway.
I do not intend to ship this for < F9 unless today's changes in
libwmf-0.2.8.4-18 will be shipped for them as updates.