GnuCash Documentation in PDF format
david.goodenough at linkchoose.co.uk
Sat Jun 20 05:19:41 EDT 2009
On Friday 19 June 2009, Clark wrote:
> I used Adobe Acrobat Pro to do a pre-press on the PDF. The images which
> print too big are specified to be at 75 DPI, the ones that print right
> are about 120~126 DPI. In all cases the numbers are not exact, and vary
> slightly from image to image.
Given that GnuCash is an open source project, would it not be better to
use Scribus? It does a very good job generating PDFs, and also has this
kind of image scaling capabilities.
> So what is happening is that the PDF specified how many pixels wide, and
> this interacts with DPI to determine how large it will be on the paper.
> Lower DPI, larger on paper.
> Editing the PDF with vi, the PDF contains a line that specifies the
> width and height in pixels, but not the DPI. That must be encoded with
> the image somehow.
> I expect that the larger images were captured with a different process,
> for example a different PC with a different screen resolution, or on a
> PC where the X-Windows DPI was set different/incorrectly.
> Another possibility is that one or the other was edited with an
> application, for example to crop. Some applications I have run into
> strip all of the tags out of the file and put their own. Or if there is
> no resolution, put one in that they like.
> There are two ways to go from here:
>  Fix the capture files with an application that edits the tags, or
> capture new images.
>  Change the PDF coding to specify a bounding box of the image so that
> the PDF renderer will make it the desired size regardless of the number
> of pixels and resolution. This would be the preferred method.
> Googleing for PDF Referend brings me to:
> ww w.adobe.com/devnet/pdf/pdf_reference.ht ml
> Document management - Portable document format - Part1: PDF 1.7, First
> Edition (July,2008)
> Section 8.9, Images
> Specifically section 8.9.5, Image Dictionaries
> Specifically section 8.9.1 on page 209, example showing translation and
> scaling of an Xobject Image with the cm operator, and encapsulating it
> within q and Q to save and restore the graphics state, so as to not goof
> up the larger context into which the image is placed.
> Reading around a little bit confirms through implication that images are
> sized based on the number of pixels and the resolution. The example
> also reinforces this, as it is necessary to perform a transformation for
> the image to be a different size.
> ww w.adobe.com/devnet/pdf/pdf_reference_archive.ht ml contains older
> Hope this helps. Hope this works!
> Derek Atkins wrote:
> > Tom,
> > Tom Browder <tom.browder at gmail.com> writes:
> >> Derek, I'll be happy to take a look and see if I can fix at least a
> >> couple of the bad figures to see what kind of effort is involved. I
> >> don't know much docbook, but I'm sure there are various ways to
> >> manipulate a figure without having to import or make a new image file
> >> (and it shouldn't affect the same figure in other products--just pdf).
> >> I have done similar things to lots of figures with LaTeX and ConTeXt.
> > That would be most excellent! Thank you.
> > If "make pdf" is all that's needed, I can set that up as part of
> > the daily doc build on 'code'.
> >> Regards,
> >> -Tom
> >> Tom Browder
> >> Niceville, Florida
> >> USA
> > -derek
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel