[Bug 437667] Review Request: dvipdfm - A DVI to PDF converter

[bugzilla at redhat.com]

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 at 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 at 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.