Scanner Modifications to Scan Large Documents

Your average consumer scanner works well for scanning normal printed or handwritten documents, usually anything up to Letter or A4 size. For something a bit larger, say Legal or Tabloid size, one can try to scan the document in segments, but the scanner’s lip, which is great for aligning smaller documents, becomes a major hindrance, and one usually resorts to scanning the document using a copy machine if one has access to one. This is fine until one has a document that is too big for a copy machine, e.g. what I wanted to scan—old maps. They’re too big to fit in a scanner or copy machine even if one tried to fit part in at a time; besides, one shouldn’t try that since they’re old and irreplaceable. One could photography them, but one needs a scanning back camera to get anywhere near comparable resolution, which are really expensive. That is where this modification comes in—modifying a low-cost, off-the-shelf consumer scanner to scan arbitrarily large documents in segments, which are then assembled via software.

We start with a Canon LiDE 90 scanner, although any scanner in the Canon LiDE series will do as they’re all similar.

Unmodified Canon LiDE 90 Scanner

Continue reading

Posted in | Tagged , , , , , | 63 Comments

Finishing Google Summer of Code

I have now merged the second phase of my Google Summer of Code project, unit support improvements, into the Inkscape trunk. Back in April when I proposed this project, I thought refactoring Inkscape’s unit support would be the easier part of the project and improving the unit support would be the more difficult part. In retrospect, the opposite was true. To refactor Inkscape’s unit support, I had to learn the details of all the different unit handling systems and become familiar with the rest of the code they interacted with. Inkscape contains over 500k lines of code, and learning the code base was the most time consuming part of this project. By the time I finished phase one, I was familiar with the unit support code and the code that used it, so extending unit support was fairly straightforward. The most difficult part of phase two was tracking down and fixing transform bugs the were manifested during document unit changes.

Highlights of phase two include:

  • Use of real world units for page sizes
  • Use of real world document units via a viewBox
  • Refactor of expression evaluator and addition of exponent operator to it
  • Addition of expression evaluator support to toolbars

Continue reading

Posted in | Tagged , , , | Leave a comment

Bug Fixes

I have devoted the past two weeks to fixing bugs in my viewBox based document unit implementation, deciding against implementing the object specific units I mentioned in my previous post. The most serious bug fixed was a bug that caused new objects to be defined in px with a transformation back to the document unit. A majority of the other bugs fixed were bugs in the transformations performed when changing the document unit from one unit to another. Just about everything is working properly now. With the Google Summer of Code drawing to close, I plan on fixing any remaining bugs I can find and merging my branch with the Inkscape trunk in the coming week.

Posted in | Tagged , , , | Leave a comment

Document and Object Units

I have now implemented pages sizes using real world units as well as document units using a viewBox as described in my previous post. Although it is mostly working, there are a few known bugs when changing the document unit, namely connectors and 3d boxes do not scale properly. I have also worked on fixing regressions introduced by the phase one unit refactor.

Besides document-wide units, it is also useful to have object specific units for convenience. As real world units are handled as scaling factors of the document unit by the SVG specification, they are only recommended for the document size, not individual objects, and their values are counterintuitive when a viewBox is used to specify document-wide units. Therefore, I’ve decided to implement object specific units using an inkscape:unit attribute instead, which will also allow for units not defined in the SVG specification, e.g. feet. The manner in which object sizes and positions are written to a SVG file will not change; the attribute will only be used to remember which unit should be displayed when an object is selected in the Inkscape UI.
Continue reading

Posted in | Tagged , , , | Leave a comment

Analysis of SVG Units

Since my last update, my branch for phase one of my Google Summer of Code project, unit refactoring, has been merged into the Inkscape trunk. I have now created a new branch for phase two, improvement of unit support. In order to improve unit support, one must first start with how units are defined in the SVG specification. In SVG, there are two types of coordinates, those defined in user space and those defined in real world units. If no unit is specified, it is assumed to be in user space units. By defining the document size in real world units and applying an equivalent viewBox attribute, one can define the user space unit to be a real world unit, e.g. millimeters.

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="74mm" height="52mm" version="1.1"
     viewBox="0 0 74 52" xmlns="http://www.w3.org/2000/svg">
  <!-- The dimensions for this rectange are given in user space, but
       due to the viewBox attribute having the same values as the
       document size specified in millimeters, the user units are
       millimeters. -->
  <rect x="10" y="5" width="30" height="20"></rect>
</svg>


Viewbox diagram

As the width and height of the document are 74mm and 52mm respectively and the viewBox stretches the user space width from 0 to 74 and the user space height from 0 to 52, the user space unit is equivalent to millimeters.
Continue reading

Posted in | Tagged , , , | 3 Comments