Digilabs Technologies Blog

Digilabs has had the privilege to sponsor & exhibit at the Infotrends Digital Imaging and the  Photo Publishing Summits at the Hyatt Regency in Burlingame, CA this whole week!   Not only have we met a lot of new and exciting people (and many of our happy customers !) but we’ve also learned a lot of the ‘buzz’  (and as you see in the pictures, also some  ‘booz’) of what’s going on currently in the photo publishing market.


It was also a great opportunity to demo a the beta version of our new My Photo Creations (temporary name) software that should be coming out late fall as well as hear some actual feedback!  And let’s just say the response was glowing!!!

We have also participated in the Print 09 show in Chicago. More on that in a different post.

When NASA first started sending up astronauts, they discovered that ball-point pens would not work in zero gravity. However, they still needed a way to write. To combat this problem, NASA scientists went to work, developing a pen that writes in zero gravity. A decade and $12 million later, they came up with a pen that writes in zero gravity, upside down, underwater, on almost any surface including glass and at temperatures ranging from below freezing to over 300C.

When confronted with the same problem, the Russians used a pencil.

This is, by the way, am urban legend. Didn’t happen. If you want to know what did happen you’ll have to read to the end of the post.

Despite that, everybody likes the story. We all like stories that demonstrate the government waste and bureaucratic stupidity. But I brought it for a different reason. When I’ve first heard this story, years back in school, I’ve seen something else in it. Naturally, I didn’t know to much about governments then…

I’ve seen it is something else. That is, our tendency to think about solutions to problems, and not about the problems themselves. My high school math teacher used to say that understanding the solutions is 1/2 the way to the answer. Over the years I learned to appreciate this lesson, although I think he under estimated it. I think understanding the problem is more like 3/4 of the solution.

What is the difference between the two? Imagine the year is 1969. You are a NASA engineer, and your boss came you with a problem: “We found that ball-point pens would not work in zero gravity, can you build me a pen that can write in space?”. What are you going to do? You will go to work to create a pen that can write in zero gravity. And being a brilliant NASA engineer, working with other brilliant engineers, what else can you do? You will come up with a space pen.

The problem is that once your boss changed the problem definition from “how can we keep notes in space” to “how do I get a pen to write in zero gravity” he also, without noticing, changed the problem. He already solved it to say “we will use a pen” and reduced it to a mechanical questions of building this pen. You see, the problem “how can we keep notes in space” can be answered in many different ways, where pen is only one of them. What about a pencil, a laptop (okay, they didn’t have those then, but maybe this is what they needed to develop?), an iPhone, a piece of caulk, using copy paper, and you can come up with another 10 ways if you put your mind to it. Once you reduced the problem to “how do I get a pen to write in zero gravity” we are left with a mechanical question of “how to build a space pen”, which, by the way, engineers like, but might have nothing or little to do with the original problem of taking notes in space. So you end up with a space pen.

In my job I do get customer feedback, and often, it involves suggestions. For me, when I get a suggestion, I always ask what are you are trying to solve and why? Some people take it as an offense. After all, I am the customer, I know what I am talking about, and as the customer, I am always right. I don’t question all of that. What I question is something else. Since most often than not, the “problem” is defined already as a solution, I want to make sure I understand the problem well enough to see if the proposed solution is the right one. In other words, I don’t question the need to take notes in space. I want to verify what is it behind the “how do I get a pen to write in zero gravity” problem. I want to uncover the real problem that needs solving so I end up with the pencil and not the space pen.

So next time when you feel I grill you with those detailed questions that seem to go nowhere and focus around small details, (such as how do you envision this zero gravity pen will be used? when will they use it? Who will use? Does it have to be ink? What will they use it for? Why do you want it…), cut me some slack. It’s not you I question. It is me trying to understand.

Okay, so what is the real space pen story? As I said, the story above is a myth. The space pen is real, in use until today, and does solve some real problems that pencil have.  The space pen was developed by Paul Fisher, the founder of the Fisher pen company, who also created his “bullet pen”  in the 1940’s, which became one of the best-selling pens of the Twentieth Century. Fisher perfected a pen that was sealed with pressure inside of the cartridge that made the ink to flow regardless of gravity. It took him 2 years and $2 million to develop. NASA chose the pen in 1967 for use by Apollo astronauts and it’s been a part of space travel ever since. For the Apollo mission, NASA had purchased 400 pens at $6 each. Prior to 1967, there were no pens that worked in space so there were pencils used. NASA preferred the use of the pen as there were concerned about pencil dust floating around as well as fears that if the tip of a pencil broke off and drifted into the electronics. For the same reasons, the Russians also use the space pen.

To learn about the space pen technology click here. Yes, the space pen is still around. You can even buy on this site a space pen for around $25.

In the  previous posts we spoke about  image resolution, scaling, and graphics, and how a flat PDF file, or a raster PDF, can result in reduction in quality of the final printed page. However, this is actually the small part. There are more.

When you raster all the page to a single image, it all blends together. Once it’s blended together, it is pretty hard to break it back into pieces. (Okay, I say pretty hard and not impossible just for the chance that some kid in Silicon Vally (or Bangalore, whatever)) is working in his garage on this next big thing). I think there is a say about how much easier is it to break an egg than to put it back together. This should not come as a surprise. This rhyme, printed on 1810, with origins in the 15tn century, already said it all.

    Humpty Dumpty sat on a wall,
    Humpty Dumpty had a great fall.
    All the king’s horses,
    And all the king’s men,
    Couldn’t put Humpty together again.

So, what does that have to do with your PDF’s you ask? allot.

Lets say you are a professional lab. You charge premium prices and provide top notch work. You have a person on staff that actually looks at the files before you print them. Now, this guy comes to you and says something like that. “Hey Sara, I got here this book from our customer. I see a problem in the book, what should I do”. Well, if your file is a raster PDF there’s not to much you can do. However, if it is a vector PDF there is allot you can do.

You can, for example, open the file in Adobe Acrobat Professional (or probably any other PDF editing tools) and actually edit the file. You can delete this empty image that was left in by mistake. Or move the text somewhat from the edge of the page if needed. Even delete the text and add new one to fix a typo. Or, you can open an image in PhotoShop to fix its color gamma if needed. Don’t get me wrong. Not that you want or need to fix every job, but when the need arises, wouldn’t you like to be able to do it.

But what if you are a big printer. You don’t inspect every file and opening a file in PhotoShop sounds like a nightmare? Well, there are products out there that will read PDF files (as well as image files) and automatically enhance there images. They can produce magic, from color correction, white balancing to sharpening and noise reduction. They have it all.

Products from HP Indigo, XEROX, KODAK, Athentech, and there are probably few more I failed to mention. All those solutions can improve your printed output quality while integrating in an automated work flow. You will not need to look or touch the files in order to get better print quality (and more satisfied customers). The key, however, is the ability to look at the individual images and enhance them individually. Working on a full page can be useful for noise reduction, but that’s about it.

So, a vector PDF gives you smaller files, higher quality, and the ability to enhance and fix your output later. So, you ask, why would anyone generate non vector PDF’s? Well, you want to know why? Because its easier! at least for the programmers. Do you really willing to accept this as valid reason?

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.


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.


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.


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.


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.


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.


Subscribe to my feed
April 2020