Mercurial > cgi-bin > hgweb.cgi > ImagePrep
view Readme.html @ 16:2bb46da74667
Detect unsupported file types on input.
author | David Barts <n5jrn@me.com> |
---|---|
date | Mon, 20 Jul 2020 12:56:07 -0700 |
parents | 70b4d11ebbb9 |
children | 404eb7e57fe6 |
line wrap: on
line source
<!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>.properties</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>.</code><code>properties</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 override it with a command-line argument.</p> <p>Ah, the command-line. Because it’s not a full “clickable” app, it is launched from the command line, and accepts arguments, much like the old days of using X Windows. This is actually <em>more</em> user-friendly for my purposes, because it ends up honoring the concept of the current working directory. (Directory management is one area where GUI programs fall short.)</p> <p>The current working directory is the input files directory. Depending on how the properties are configured, the output directory is either the current working directory, or a specified output file directory. Both directories act like a current working directory; the next time an input or output dialog is brought up in a given session, it will be in the same spot the previous dialog was when it was closed. All this makes it easy to rapidly edit files in a directory of images downloaded from a camera, without polluting that directory with the edited files.</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. They are one operation, because that makes the program easier <em>for me</em> to use.</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>