Digilabs Technologies Blog

Archive for June 2009

In the previous post we spoke about  image resolution, scaling, and graphics. So, how is that related to the various types of PDF?

A PDF can be built of two types of graphics objects. Vector graphics and raster images. Vector graphics in PDF, as in PostScript, are constructed with paths. Vector graphics are what I called in the last post line art. A line art is an image that is better defined as a combination of lines, curves and colors. Raster images, on the other side, are defined by a grid of pixels. This is what I called a continuous tone or a bitmap.

A vector PDF is built out those two graphic object types. Each image is kept separated to itself and is represented by a raster, while other art, like text, lines or clip art is represented by vector graphics objects. (The “Each image is kept separated to itself…” thing is important. I’ll get to it latter in post III)

A raster PDF is a PDF where all objects on the page were converted first into a raster graphic, such as a jpeg/tiff image, and than added to the PDF as a complete page.

In the previous post I showed why scaling the vector as a vector produces better results than scaling the raster (or bitmap). That’s obvious. However, is this really the case with a PDF? After all, we can raster the image to the resolution we want it to be printed anyway so we will not need to scale later.

Well, if just life was so simple. What happens is that not all resolutions are created equal. Or maybe its more correct to say that not all graphics are created equal when it comes to resolution?

When we look at an image, out eyes will view it as a continues tone. As such, our eyes can not see the difference in resolution (or more pixel data) at one point. Print at 300 dpi and above, it all looks the same. Between 200-300, its pretty good but the trained eye will notice. Print at than 200 dpi or less and you will likely notice. Print at less than a 100 and, well, just don’t go there.

When we look at line art or text or clip art, our eyes are less forgiving. Look at text for example. While an image is built of pixels that change all the time, a character has a solid color and ends at once on an edge. You have a curved line, and than you don’t! Our eye sees that. This why in the traditional repress industry, text is eventually converted into a raster at anywhere between 1200-2400 dpi. If you don’t believe me, go print some black text on your favorite laser printer and look at it really close. Look at a X or a B, look at thin text, and you’ll see. Same goes for clip arts and lines.

So now, you have a problem. What dpi should I raster my page is I go with a raster PDF? 300 dpi is good for the images, but only reasonably okay for my text and clip art. Or, I can raster to 1200 dpi. That will work,with a cost. When I save my images at 1200 dpi they are not 4 times bigger than a 300 dpi but 16 times bigger! (yes, its not 4 but 4 times 4). So if a page in my calendar is 8.5×11, at a 300 dpi raster it will be, roughly, 2 MB, depending on the compression level I am willing to take. The same page, at 1200 dpi, will be come 32 MB. Given a calendar might have 26 pages, my calendar just grew from around 50 MB to around 850 MB. This by itself is enough to kill this idea, which is does. Almost anyone will do it to 300 dpi or less. Some will settle on 200 as well. The temptation (and the files) are just to big. There are even more problems intreduced into the page tis way, but lets ignore them. They are small compared to this one anyway.

To sum it up. Your print will not look as good as it can, especialy text and graphics.

To be honest, this might not be a big deal. Many customers, at least at this stage of the game will not notice anyway. If you do not have allot of text or clip arts this is not even a problem. On the other hand, why be less than you can be?

This however, is the smaller problem of raster PDFs. The next post will describe the main problem. If you want a hint, rememebr the sentence: “Each image is kept separated to itself…”? The next post will discuss why keeping each graphics ellemnt separate is a big deal, even if we evntualy print them on the same page.

One of the many different things we prepare our output is the usage of a Vector PDF. But what’s the big deal? Doesn’t PDF stand for a Portable Document Format? Isn’t a PDF just a PDF?

This turned out to be a long post. Longer than I thought it will be when i started. So, I broke it into three parts. The first part will layout the basics. Some of you might find it doesn’t tell them anything they don’t know already. Feel free to skip it if this is the case. The second post will tie it all together with emphasis on printing and output.

Well, a PDF is indeed a portable document, and it will look “the same” on different devices. It just does not mean that all PDF’s are created equal. In other words, looking the same is the not the same as looking the best it can. So the way the PDF is built will effect the results you get, even if you don’t know it yet.

Let me explain. Many of you might know it already, but some who are new to the world of digital printing might not yet be aware of all those details. I’ll try to put some sense into it all. I will avoid many technical details, but we’ll have to go into some of it from time to time.

We live in an analog world. In this world things are continues. I draw a line. I take my pencil, start form one point and go to another point and I have a line the width of my pencil. I’ll take a magnifying glass and look at it, it’s there! It’s looks wider, but is still the same line I drew. That is the analog world.

A digital world, buy contrast, uses discontinuous values. The combination of a series of discontinuous values may fool us to think it is continues when in fact it is not. In real life we move around. This is analog. In the movies, the actors picture on the screen change at 30 frames per second, fooling our brain to think they are moving when in fact its a combination of discontinuous frames. This is digital.

Computers are digital. The screen is a digital device. It is built out of many small points that can be turned on or off, and if you put a lot of them inside a tiny place it might fool the eye, but this is still a visual effect, not reality.

Enough with this mambo jumbo! lets add some context. Remember the line I drew in the first paragraph? Lets draw it on a computer screen. I have a starting point and an end point. I turn pixels on the screen on and off to get the illusion of the line. But since the screen is digital, pixels are either on or off, and since my screen is a matrix of discontinuous pixels, they don’t always fall where the line should be. On the left, you can see my line on paper. On the right, how the same line might be represented on a screen.

line

Okay, I admit. I did simplify things somewhat. Many smart people make a good living doing a better job in representing this line. They will use all kind of smoothing techniques, such as anti-aliasing or others to get better results, but you get the point.

When we represent things on screen or paper, we can divide our inputs into two camps. The continuous tone camp and the line art camp.

For simplicity, lets say digital images are better represented by a continuous tone representation. In the real world it means a big array of pixels, each one with its own color. When enough pixels are crammed together is a small place, they fool the eye to look like a continuous tone image. We will call the number of pixels we put together in a given space the “display resolution”. There are more than one usage for the term resolution, but here we actually mean: “how many dots per inch do we have”. So when we say the image is displayed at 72 dots per inch (dpi), we actually say that when we display it on the screen, every square inch of the image contains an array of 72 by 72 pixels with color information in each. We can refer to this graphical representation as a bitmap (or a pixel map) image.

The image on the right is a small image on a scree. On the left, you can see what it really looks like on the screen if we look through a magnifier.

pixels

On the other end of the spectrum, we have the line arts. A line art is an image that is better defined as a combination of lines, curves and colors. Think about a clip-art or a cartoon. It is easier defines as a series of strokes, lines, geometrical shapes and colors than by a bitmap. Since those images are defined by geometrical shapes, they do not have an inherited resolution. I can take the geometrical shapes and scale them mathematically to any size I want before I render them to the screen (which we know by now is a digital device). So, when I use a line art image, I can get the best possible result for the specific output device. But more on that later.

I know. By this time you all nod your head in understanding, but back in your mind you think, “who cares?”. After all, we mostly print and and deal with images, right? Wrong! The most common form of a “line art” we use are fonts. Okay, fonts are more complex than a typical line art and someone out there is annoyed by me treating them the same. So let me say just that. Fonts are more complex in their technology and definition and usage than I might suggest here, but for our little discussion lets define “line art” as anything that can be defined with lines and curves, including fonts.

How do you make a font look good at all sizes? Fonts, or at least modern fonts (like truetype or postcript), are defined as mathematical definitions of lines and curves to shape the look of a character. When displayed or printed, they are first mathematically scaled to the desired size and than are rendered to the output device. Did I say no inherited resolution? I guess the term resolution independent is a better term to use.

Look at those two example.

When we represent what should be a line art as a bitmap image, we impose a resolution on the item first. From now one, if we scale it, we always start with its resolution, same as the example of the image above. On the left we see the letter D. On the right is the top part of the same letter at a larger size. Since we started form a bitmap of the letter D and scaled it up, look how it looks like. This is called pixelation.

font2

Below we have the same text, but this time, we started with the line art description of the font and kept it this way until the last minute before displaying it on screen. Note how the lines look compared to the same text above.

font

This is true not only for fonts, but for anything which is better described as a line art. Take a look at the clip art below. Left is the original, center when scaled from a bitmap and right when scaled from a vector file.

clip

So what all of that has to do with PDF quality? This will be the subject of the next post.

Juts got an email from a customer. It went something like that: ” …., I walked a 70+ year old woman successfully through building her first photo book (over the phone!)… this software is the absolute greatest. And she thinks I’m wonderful, when in fact, it is your software. Thanks, for making me look like a hero!”.

Getting this type of feedback is definitely nice and makes me feel good, okay, really good!. Second to getting this type of feedback, is getting a not-so-pleasant feedback. It might not be pleasant, but it is feedback. At least someone cares enough to tell you what he feels. Not getting any feedback is the worst. That shows no one cares anymore. That hurts.

So, a word about feedback, responses, actions, and timetables.

Lets make one thing clear. We would like to get your feedback!!! We value it and it helps us tremendously. What you like or dislike. Changes and suggestions you would like to see in the software. Suggestions on the process. Anything you feel you want us to know. It can be an email, on the phone, or just stepping into our booth in a trade show. Whatever and whenever you feel like.

We might not always agree with everything (although even boneheaded programmers get the message when they hear it again and again). In fact, we might get conflicting opinions from different people. After all, if we all liked the same things the world would be a really boring place. But I can promise this. We are going to listen. We will digest it and try to fully understand the underlining issue. Sometimes you will suggest a solution, so we will try to understand the problem and see, maybe, just maybe, we can come up with a better (or simpler or faster) solution to the problem. We will balance it all together, add what we have on the table, and see how and when to act.

Its a balancing act of requirements, priorities, resources, risk, and schedules. Doing good work takes time, so results might not show up as fast as you think they should. That does not mean we ignore what you had to say!!! It just that reaching to the peek of the mountain is build out of many small steps, one step at a time, so we keep walking, and walking, one step at a time.

I just finished working on a problem. I might say it feels pretty good to find a real problem that was hiding somewhere and nail it down. The fix was quite simple, not more than 5 minutes work. However, it took me about 6 hours to find what is the problem, or should i say four weeks, 6 hours, and 5 minutes?

It all started, like many other cases, with a customer support email. Some question about something. Emails went back and forth, suggestions were raised, information was requested, and so it went on and on. The problem, you see, is that if the problem this customer had was so obvious, we would see it as well. But we typically don’t! because typically, it is not so obvious.

The problem is that in order to fix we need first to understand, and in order to understand we need to see. And if we can not see it, at least we can see all kind of other information that will gives us clues. So it took us 4 weeks to see it, 6 hours to understand what is going on and when it happens, and once all was in place, 5 minutes to fix it.

So why did it take 4 weeks to see it? Why couldn’t we see it on the first problem report?

This is what we call bug reporting. When you go to the doctor, you try to tell him what is wrong and why did you come to him. You will not say “I feel horrible and I need Xortoplex and I need it now since I have a very important meeting and if you had half a brain you would know what it is and fix me up now”. Well, you’ll be surprised how many bug reports sound this way. Now, don’t get me wrong. I don’t mind the half a brain thing, nor the conclusion that Xortoplex is needed. What I mind is that the problem report has no useful information I can use to start answering the problem. Something like “I have a headache and fever. I vomited twice since breakfast and my teeth are falling.”. Now, if after that you would like to add that last time Xortoplex worked wonders that is fine, but that can not come instead of a report of the problem.

So, how can we report a problem in a way we can reposed effectively and solve it? This is a great article that will better explain what are we looking for in a report and why.

To sum it up, here are a few rules of thumb for effective reporting.

* Keep in mind that we are on the same side! We want to help. We want to solve the problem. Since we do not sit in your office and did not see the problem, we need your help. The more information we get, the faster we can understand what the issue is, the faster we can respond.

* The best outcome of the report is to have the programmer see the failure with their own eyes. Since they can’t be with you when that happens, give them detailed instructions so that they can make it fail for themselves. If you can attach screen shots, please do. If you have files used or generated, such as images, PDF files, log files, please send them.

* In case the programmer can’t see it failing themselves, he needs to understand what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down error messages, if they were. Like above, files used in the process, like image files, PDF files and log files ate worth their weight in gold.

* By all means try to diagnose the fault yourself, but even if you do, you should still report the symptoms.

* Be ready to provide extra information if the programmer needs it. If they didn’t need it, they wouldn’t be asking for it. They aren’t being deliberately awkward. Any information on your system will help, OS, version, memory, hard drive, images used….. Better, just send this information in the first place. Be aware that small details you don’t see as important might be very important.

* Write clearly. Say what you mean, and make sure it can’t be misinterpreted. “It crashed” might be interpreted in many ways, and so does “it didn’t work”. One liners are great for punch lines, but are pretty useless for problem diagnostics. Don’t worry. You can not over explain.

Anyway, if you missed it above, it is well written and easy reading.

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Latest pictures form Print China. Note the logo on the center stage.

China1

DSC0465