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@xxxxxxxxx 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@xxxxxxxxx> - 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review