Often, people copy images from Wikipedia without citation. Of those who do cite their photos, many just cite “Wikipedia” or “Wikimedia Commons,” which does not attribute the photographer and therefore does not constitute a proper citation. Due to this common mistake, I have compiled a list of ten things that are analogous to only citing “Wikimedia Commons” instead of the photographer when using photos from Wikipedia.
- Attributing a book you read to the library you borrowed it from
- Referring to a painting by the art museum it’s hanging in
- Attributing a speech to the country it was given in
- Calling a pixel a photograph
- Attributing Don Quixote to Homo sapiens
- Calling a brick a building
- Referring to the cherry on top of your sundae as a sundae
- Calling “k” the alphabet
- Referring to 261.6Hz as Sing Sing Sing
- Calling an atom a car
When using a photo from Wikipedia that has a license that requires attribution, always include the photographer in the citation and preferably link to the source of the photo. The photographer is the copyright holder, not the Wikimedia Foundation, and therefore requires attribution. Also see Wikimedia Commons’ pages on reusing content and credit lines.
Since last summer, I’ve been working on a map of Camp Workcoeman. A time consuming aspect of that has been finding and mapping the property bounds, and I’ve spent quite a bit of time researching the deeds for the various parcels. While this gave me an idea of what was acquired when, it was still words, headings, and distances on paper that don’t do the real world geography justice. I have therefore compiled a map of the parcels, including when the camp acquired the land and from whom, which is far more illuminating.
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.
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
- Refactor of expression evaluator and addition of exponent operator to it
- Addition of expression evaluator support to toolbars
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.