Paper sizes

[xuv]

A feature request I mentioned already in #20 discussion but moved here for clarity:

The user could maybe determine a canvas size while loading the drawing. Let's say if someone draws on a A4, A5 or A6, in portrait or landscape. Because when you draw, you usually draw in relation to the limits of the paper you're drawing on and work on the composition of that drawing in the page. So maybe if the user would say what are the page dimensions he or she was working on, the composition could be kept in the output file. (It could be presets like A3_landscape or A5_portrait. or 200x200mm). That, I think, would be a useful option.

Note: It's also a feature available in the "official" wacom software.

[roelj]

Preset formats would be cool and not so hard to do.
Any dimension is supported already using:

--dimensions=210x297mm

Or in a config file:

dimensions = 210x297mm

Would it be a problem when only millimeters are supported?

[xuv]

This is great.
Maybe exposing this in the gui would be nice.

All these great command-line examples should be put somewhere in the documentation.
For example, I had to read your code to figure out that the --merge option is writing over the second file (and maybe I'm wrong).

Should I add these examples in a "usage" section in the README file? Or elsewhere?

[su-v]

The current version of the Inkscape WPI input extension (at the moment still maintained in the gist, sorry) does offer preset papersizes as option (the input dialog currently only lists a few in the dropdown, cherry-picked from a dict in the python script with all predefined paper formats from Inkscape - that dict of formats could be changed though, e.g. to what Ghostscript uses, or to what presets inklingreader will support in the future).

[roelj]

@xuv: I just pushed my completely incomplete start of a user guide. I prefer the Texinfo format because it tends to be cleaner than plain (La)TeX and it works well with version control systems.

Adding them in the README and README.md is fine. Could you also add them to the user guide?
I'll work out example usages as well (I think I know all intended options and their precise behavior :)).

@su-v: Good to see progress on the extension! You almost made InklingReader's GUI obsolete :-). Maybe we can meet on IRC sometime and figure out the git stuff.. I'm pretty sure I can help you with it.

I think the presets Inkscape uses are useful and most common.. So I'll try to implement them all in a way that we can easily add/remove them (possibly on run-time!)...

[xuv]

@roelj: Of course you are the ideal person to write the documentation. :) I just feel like I'm the dude asking for all the features and not doing anything. So I thought I might get my hands a little dirty and try to add to the doc (with the knowledge I have so far of the software). Will look into TexInfo and see how that works :) Thx.

[roelj]

@xuv: I'm mainly working on code changes, so documentation lacks behind. I added you as a contributor so you have git push access as well. It would be awesome if you could work on the documentation. I'll help out where needed (for example with the details of using the command-line options).

[xuv]

@su-v : Wow, that Inkscape extension. I just took the time to try it out. It's just awesome. Full options. Makes me want to draw some doge. Thanks a lot for this.

[su-v]

@xuv: thx :-) The current dialog is somewhat a compromise to support both stable 0.48 and trunk (upcoming 0.91). It looks a bit nicer with trunk (bold section headers), but should be ok with stable too.

@roelj: re IRC, I'm on freenode most of the time (#inkscape, #inkscape-devel, nick su_v)

[roelj]

I've added support for preset formats (the same list as the Inkscape extension) on the command-line. I'll add this to the GUI a little later.

[roelj]

Preset formats are supported in the GUI now too, however, the command-line options don't play nice with the GUI options yet.

[xuv]

Just tested the Presets in the GUI. Works great.

Just a simple question:
The way to use the Inkling is to clip the "receiver" at the "relative" top and middle of the drawing area, no?

So right now, ant this is only visible in a preset other than A4, the drawing is always starting from top left corner. Which is really strange if you use smaller or bigger than A4. I guess drawings should be relative to the top center of the page.

[roelj]

That is indeed the wrong behavior. I tried to improve this behavior in e09bc3c.

It is not perfect though. I'll investigate this further.

[roelj]

I gave this some more thought. And I think the behaviour is correct right now. The position of the drawing is always related to where the receiver was at the time of drawing. When you really draw on an A5 or on an A3 paper, You will draw within the boundaries of the page and what is displayed digitally is what you've done on paper.

[xuv]

Mmmh. I've tested with the A3-A6 test files I also gave you + some others, and I have the impression the overall drawing is pushed down too much. I have lines at the bottom of the drawing that always go beyond the white canvas.