GnuCash Documentation in PDF format

[David Goodenough]

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.

David
>
> 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:
>
> [1] Fix the capture files with an application that edits the tags, or
> capture new images.
>
> [2] 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
> versions.
>
> Hope this helps.  Hope this works!
>
> --Ray
>
> 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
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel