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.brow...@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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
