Mercurial > cgi-bin > hgweb.cgi > ImagePrep
diff Readme.html @ 0:e0efe7848130
Initial commit. Untested!
| author | David Barts <davidb@stashtea.com> |
|---|---|
| date | Thu, 16 Jul 2020 19:57:23 -0700 |
| parents | |
| children | 70b4d11ebbb9 |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Readme.html Thu Jul 16 19:57:23 2020 -0700 @@ -0,0 +1,58 @@ +<!DOCTYPE html> +<html> + <head> + <meta http-equiv="content-type" content="text/html; charset=UTF-8"> + <title>ImagePrep Read Me</title> + <style> +html { font-family: "TeX Gyre Schola", serif; } +h1, h2, h3, h4, h5, h6 { font-family: "Avenir Next", sans-serif; } +pre, code, kbd, samp { font-family: "Menlo", monospace; font-size: 85%; } + </style> + </head> + <body> + <h1>ImagePrep Read Me</h1> + <p>This is a simple program mainly created for my own benefit.</p> + <p>Because it is primarily for my own benefit, it does not build to a + “clickable” app. That is too much of a pain to implement.</p> + <p>Because I have code to crib, it does contain a help file. It’s pretty + rudimentary, however.</p> + <p>Because I have code to crib, it does run on a <code>.preferences</code> + file, but because coding preferences dialogs is something of a pain, it + does not contain a preferences or settings dialog, even though there is + some code to crib for both. The <code>.preferences</code> file must be + edited by hand* (it will live in the normal place for such files on the + system being run under). If no such file exists, a default one will be + created. The only things in it will be the maximum dimension to clamp to, + where the output file goes by default, and maybe what the output file’s + name is by default (i.e. a name suffix).</p> + <p>* This program is <em>for my own benefit</em>, and <em>I</em> have no + problem editing text files, therefore this is reasonable.</p> + <p>Contrary to JpegWasher, which is designed for batch processing, this will + have more of a “document editor” style of design. Meaning, you open a + file, you edit it, you save it, you close it.</p> + <p>Upon opening a file, it will be auto-scaled to the specified maximum + dimension. This will default to the value in the preferences file, but the + user will be able to change it at open time.</p> + <p>At that point, the editing step begins. It is extremely simple and is + limited to rotation. Three types of rotation will be offered, 90° + clockwise, 180°, and 90° counterclockwise.</p> + <p>The user can rotate the file as many times as s/he wants. Sort of silly, + but sometimes people are tired and get clockwise and counterclockwise + confused, so might as well give ’em a chance to fix their mistakes. Plus, + it would take special effort <em>not</em> to allow this.</p> + <p>Then comes the closing and saving. It <em>might</em> make the most sense + to wrap these two up into one operation, given that there are two + operations in one when one opens the thing, too*. (Sort of a compromise + between a classic “document editor” design and a batch-processing design.) + This will default to the name and directory consistent with the + preferences settings, but it will be based around a file dialog so that + the user can save the resized image anyplace, with any name.</p> + <p>* Leaning towards making “close & save” one operation; again, this + program is primarily for <em>my</em> benefit.</p> + <p>Ideally, I wouldn’t even puts around with making this a GUI app in the + first place. It’s for my own use, so the command line would be good + enough. The problem is rotation: it’s a hot mess. There’s really no way to + do it right save to show the image to a human and let him (me) decide + which way is up.</p> + </body> +</html>