# What the difference is, between a Native and a Scanned PDF File.

As the subject line suggests, this posting will just define the subject of Native versus Scanned PDF Files.

I have encountered people who simply regard PDF Files as a convenient way to scan a stack of images – from paper – and to store those images. The resulting Scanned PDF Files do have advantages over certain other image formats, such that:

• They can be password-protected, locked, ‘DRM’ed, etc.,
• They keep track of a document consisting of more than one actual image, aka page.

But their main disadvantage is, that because they were scanned, they are also rasterized, which means that they have a fixed resolution in pixels. (‘Rasterized’ images are also referred to as ‘Pixel-Maps’ or ‘Bit-Maps’.) I supppose that if a paper document is being scanned, this is not a big deal, because the original document had a limit in its physical level of detail. (:1) But as an alternative, Native PDF Files also exist.

In order to understand what those are, the reader needs to be aware that a form of graphics exists in general, which is an alternative to pixel-based graphics, and that is called ‘Vector-Based Graphics’. What this form of graphics entails is, that there exists a Mathematical definition of a curve, which is often also referred to as a ‘Path’, the parameters of which can be changed from one path to the next. Those parameters need to state in floating-point numbers, where the endpoints of the path are, and, preferably, define what the derivative of the curve is at both endpoints. The most standard type of Mathematical function that does this is a Cubic Spline, but that is by no means the only function available.

A vector-based image consists of a collection of paths, each of which has a different set of these numerical parameters, even in cases where the function is always the same. Also, there often needs to be a stored detail, of how to render such paths, such as to fill in the area inside a closed path with a fill colour, etc..

What is the advantage of this? The resulting image can be zoomed to any size, and not lose its precision. Unlike the raster-based images, which:

• Become unsharp,
• Suffer from filtering artifacts,

…When resampled, vector-based graphics lose no detail when just resized. They stay sharp. And one form of vector-based graphics which every reader of my blog has seen before, is actually a typical font. Fonts are usually not stored as pixel-maps, but rather in some vector-based language. One such language resides in the ‘TrueType’ fonts that Windows uses. But another lies in the ‘OpenType’ fonts that Linux uses. They can be displayed at whatever the screen resolution is and stay sharp.

There is a catch to the wonders of vector graphics however. Because most display devices are raster-based, even vector graphics of any type eventually need to be rasterized once, in order to be displayed, let’s say at the screen resolution. But, they should only be rasterized once, when finally output. They should not be rasterized and then rescanned. Don’t laugh; it has happened to people that they lost track of how many times they have rescanned an image.

Well, a Native PDF File is one, that also contains certain elements, that are vector-based. Thus, typical PDF Files have more than one layer, one of which might be a (vector-based) text layer, and another of which might be a raster-based image layer. Yet, there is nothing that prevents PDFs’ vector layer from containing other types of figures, than just text. The mechanism can be expanded, because for the sake of argument, a font can be defined and embedded, the glyphs of which are not plain letters, but rather, ‘musical notation elements’. When such a font-layer is rendered, its glyphs will be musical notes… And in that case, they will remain sharp, regardless of how greatly they are zoomed, or just displayed at different resolutions.

When I receive a PDF File, at first, I cannot know whether it was a Native PDF, or a Scanned PDF. But I’m usually happier to be working with Native PDFs.

1:)

I suppose that in today’s era, the possibility also exists that a paper document, or a Scanned PDF, can be fed through some sort of OCR software, that recognizes either as containing text, and the objective of which is to store the text, not the pixel-map. In my recollection, such OCR software ‘makes a certain number of errors’ every time it’s to convert an image into text. And so, this solution often strikes me as a cop-out, simply over the fact that the text next needs to be analyzed by a human, and often, edited.

I suppose that I should go into further detail about Cubic and Quadratic Splines. Even though Cubic Splines are often used in high-end graphics, most font definitions are based on Quadratic Splines. They are respectively, Cubic and Quadratic polynomials of an unseen parameter, and for the purpose of rendering either, rasterizing software can determine how small the increments of the parameter need to be made, because the derivative of either, at their endpoints, is easy to compute.

But, the way these splines are stored is not, in the ‘general form’ of either polynomial. Instead, the way a Cubic Spline is stored, for example, would be like this:


v = (1 - u)
x = a u3 + 3 b u2 v + 3 c u v2 + d v3



This expression can be expanded into a Cubic Polynomial, in the general form. But in this case, (a) and (d) define the endpoint-values of one coordinate, while:


3 (b - a)
3 (c - d)



Define the derivative – the direction of the path – independently for each endpoint. This makes (b) and (c) ‘handles’ of the path. In the case of Quadratic Splines, the way they are generally stored is of the form:


v = (1 - u)
x = a u2 + 2 b u v + c v2



As the reader can see, the Quadratic Spline only has one handle, (b). The way font design compensates for that is, to subdivide Quadratic Splines into sections, such that for each section, a single handle can define the derivatives at both endpoints, without resulting in apparent ‘kinks’ in the Path that results. I.e., the tangent that forms at each endpoint, must be in the reverse direction, for the two sections that meet there.

In high-end graphics, the GUI would generally control the two handles that meet in this way at each endpoint, in a way that is connected and opposite. But then, high-end graphics when used to design Cubic Splines, will also have some GUI-feature that ‘unlocks’ these handles, so that the sections that meet at each endpoint can have an independent handle-positions. And then the result is understood that the path will no longer ‘look continuous’ through the endpoint.

Dirk

This site uses Akismet to reduce spam. Learn how your comment data is processed.