Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
Glad it helped :-)

will try to better understand the mechanics of dpi versus pixel counts going forward.

Here's a try: In the world of bitmaps, only the pixel counts matter. A bitmap has a width in pixels, and a height in pixels. "DPI", or "Dots Per Inch", is as the name says a measure of how dense the pixels are in the physical world, how many of them per inch are input/output. By itself, a bitmap does not have "DPI". Only your monitor, printer and scanner have a measure of DPI. The DPI information in the bitmap header is only a hint for output!

So by itself, DPI is a measure of print quality only. It does not tell you anything about the size of the bitmap. Only in combination with a size in pixels or a size in inches or centimeters is it a measure of bitmap size. It's kind of like miles and mph, or kilometers and km/h - kilometers (DPI) are related to km/h (DPI+size), but they're measuring/expressing different things!

When you're talking to a graphics designer or a printer, they're much more used to thinking in DPI. That's why you'll need to translate between the language of "X by Y pixels" and "Z DPI at X by Y cm"/"Z DPI at X by Y pixels" - try typing "10 inches at 300 dpi" or "3000 dots / 300 dpi" into Wolfram Alpha ("dots"="pixels"). The confusion starts happening when people forget to specify a size - a designer might tell you "I need the image at 300 DPI" and forget to tell you the dimensions of the image, or "I need the image to be A5" without telling you the DPI! In my experience this happens regularly, and you'll have to get used to asking for the missing information.

Some bitmap processing tools try to be helpful to people who live in the world of DPI by specifying sizes with DPI and in/cm everywhere. They try to take into account the DPI measures of your monitor and printer, font sizes, etc. in order to try to present a world that can always be measured in inches or centimeters (and DPI). And when loading bitmaps into such software, it may take into account the DPI information stored in the bitmaps' headers. However, this world often clashes with the world of bitmaps, and people who only think in pixels - for example web designers, who are much more used to pixels.

It can be confusing, kind of like the German tourists who are regularly questioned by US Customs as to whether they want to poison their relatives!

Personally, I always just do everything in pixels, and convert to and from the language of "X by Y cm at Z DPI" only when talking to people who think in those terms.

Graphics Department: "We need the image at 600 DPI."
You: "Okay, what's the largest you want to print that at?"
Graphics Department: "We're thinking 5 by 8 cm right now but we may make it as big as 10 by 16 cm."
At this point you know you need to make the bitmap 2362 by 3780 pixels large, and that you may need to scale down the number of pixels later. Scaling down a photo is of course no problem at all, but if it contains small fonts or fine lines that won't survive the scaling down, you might need to make a second version of the bitmap.

When handing off a bitmap back to the graphics department, you just set the "print size", i.e. the DPI information in the bitmap headers, using for example the "Print Size" menu item in Gimp's "Image" menu, or the method in the above post. This does not affect the pixels at all, only the "hint" in the bitmap's header as to what DPI it was intended to be printed at (and whoever or whatever is now handling the image can choose to use any other DPI value they want).

If the graphics department comes to you later and says something like "the printer has asked for the image to be at 1200 DPI", then in my experience this issue can often be settled by simply scaling up the size of the bitmap to twice its size in pixels - even though because you've simply interpolated the image to a larger number of pixels, the quality of the image will be the same as a 600 DPI image, some printers just want a specific number of pixels per inch because that's what they're printing at (maybe the graphics department has specified that the texts on the page should be printed at 1200 DPI, and the image next to the text can't be printed at a different number of dots per inch). Only if the graphics department later complains about the quality of the image, do you have to tell them "sorry, you asked for 600 DPI and that's what you got, if you now really want 1200 DPI I'll have to redo the whole image".

That's my brain dump on the topic, HTH!


In reply to Re^3: GD @ 300dpi output by Anonymous Monk
in thread GD @ 300dpi output by themcp

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (2)
As of 2024-06-24 09:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.