Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfm - A DVI to PDF converter
https://bugzilla.redhat.com/show_bug.cgi?id=437667
------- Additional Comments From jonathan.underwood(a)gmail.com 2008-04-13 19:13 EST
-------
Spec URL:
http://jgu.fedorapeople.org/dvipdfm.spec
SRPM URL:
http://jgu.fedorapeople.org/dvipdfm-0.13.2d-36.fc9.src.rpm
* Sun Apr 14 2008 Jonathan G. Underwood <jonathan.underwood(a)gmail.com> - 0.13.2d-36
- Fix URL
- Cherry pick changes made by TeXLive 2007
- Build dvi and pdf docs
- Add Requires for tex(tex)
- Add security fix patches for temp file creation
As well as dealing with all of the comments you (Patrice) raised, I carefully
audited the changes between texlive 2007's version of dvipdfm (which is derived
from dvipdfm 0.13.2c) and upstream 0.13.2c and 0.13.2d, and applied what I think
are the few necessary changes to the packaged version (0.13.2d). I also reviewed
all related patches from Jindrich's texlive package (I hope i didn't miss any).
(In reply to comment #1)
The base page is
http://gaspra.kettering.edu/dvipdfm/
you used the dvipdfmx one...
Fixed.
There is a security issue in dvipdft since it generates files in tmp
with predictible names. In texlive dvipdfm the script comes from another
place and is furthermore patched.
Fixed.
A dot is missing at the end of %description.
Fixed.
the doc shipped should be the dvi version or even better the pdf
version.
To have the dvi, you should have a
BuildRequires: tex(tex)
and during build do something along
pushd doc
tex dvipdfm
popd
Fixed.
and add
%docs doc/dvipdfm.dvi
To have a pdf it is less obvious since the preferred way seems to
be using dvipdfm itself, but since it is not installed it is not obvious
that it will succeed. You can try anyway
pushd doc
tex dvipdfm
../dvipdfm dvipdfm
popd
and verify that it builds in mock, with an updated texlive that doesn't
contain the dvipdfm files that should be in dvipdfm.
Fixed and works.
Last issue regards the differences between config files and
corresponding
map files.
Differences are:
D "zcat -f %i | gs -q -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.2
-dUseFlateCompression=true -sOutputFile=%o - -c quit"
versus (-dSAFER added in texlive):
D "zcat -f %i | gs -q -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.2
-dUseFlateCompression=true -dSAFER -sOutputFile=%o - -c quit"
a4 in texlive
-p letter
+p a4
Fixed - now packaging the texlive config (with the original config shipped as a
doc as it contains helpful commentary).
The maps are, in dvipdfm the shipped maps:
f cmr.map
f psbase14.map
f lw35urw.map
I still include these, but they're not used.
In texlive, the font map created by updmap (and another map) are
used:
f cm-dvipdfm-fix.map
f dvipdfm.map
yes - the texlive config file will ensure these are used, I believe.
It seems to me that the dvipdfm config file in texlive is better, but I am
far from being an expert in this matter.
Yes, I think so too.
It seems to me that the config file in texlive-texmf can be kept
instead of using the one in dvipdfm. The map and enc files of dvipdfm
should still be shipped, though unused in the default fedora config.
Agreed.
A Requires: tex(tex) is also certainly missing, I don't think
that
dvipdfm will be ok without fonts. These fonts should be brought in
by kpathsea, but I think that it is better not to count on it.
Fixed.
--
Configure bugmail:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.