Mercurial > cgi-bin > hgweb.cgi > ImagePrep

<!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 &amp; 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>
author	David Barts <davidb@stashtea.com>
date	Thu, 16 Jul 2020 19:57:23 -0700
parents
children	70b4d11ebbb9