1 line
10 KiB
Groff
1 line
10 KiB
Groff
==========================
|
|
Changelog for JPEGView 3.3
|
|
==========================
|
|
|
|
----
|
|
Bugs
|
|
----
|
|
|
|
(fc1) Removed the unnecessary use of the Time Manager to measure
|
|
image drawing time, simply counting ticks instead. The alleviates
|
|
a number of system-level crashes that would occur if JPEGView
|
|
crashed during decompression.
|
|
|
|
(b5) The "Startup Screen" option in the Save As file format menu has
|
|
been changed to read "PICT Resource" so that users don't get confused
|
|
as to why their compressed startup screens won't display properly.
|
|
|
|
(b5) Small image files (<600 bytes) would be incorrectly reported as
|
|
invalid; this has been fixed.
|
|
|
|
(b5) Choosing to crop the icon only when saving, and using proportional
|
|
icons (dog-ear or no) would cause the icon cropping not to kick in.
|
|
|
|
(b5) The rectangle the icons are drawn into is now inset by 1 pixel, so
|
|
that the 1-pixel black border around the icon doesn't overwrite so much
|
|
of the actual icon image.
|
|
|
|
(b4) An unresolved alias found while searching a slide show directory
|
|
would dump JPEGView into an infinite loop or cause it to abort the
|
|
scan of the current folder. This situation should be remedied.
|
|
|
|
(b4) The Inited flag is now cleared when saving images; this seems to
|
|
force the Finder to update custom icons better.
|
|
|
|
(b3) The JPEGView JFIF Preview has been recompiled yet again. It is now
|
|
a true fat component, created according to the Component Manager 3.0 specs.
|
|
This should hopefully solve the occasional weird problems I was getting
|
|
with JFIF previews.
|
|
|
|
(b3) Slide shows with virtual memory on no longer allow offscreen bitmaps
|
|
to be created in temporary memory. This results in more paging than with
|
|
version 3.2, but it is quite tolerable -- at least on my PM6100/60av!
|
|
|
|
(b2) Certain color startup screens would not be displayed properly if there
|
|
was also a black & white version stored in the data fork. JPEGView now
|
|
checks for a color screen, and ignores the black & white one if it is
|
|
found.
|
|
|
|
(b2) Selecting the Desktop for a slide show scan finally seems to get it
|
|
right (I think!) Also, I put in a check during the slide show scan so
|
|
that infinitely-recursive alias resolution can no longer get you into
|
|
trouble!
|
|
|
|
(b2) The dog-ears on large icons are now slightly bigger, and should be
|
|
comparable to dog-ears from other apps.
|
|
|
|
(b1) Revealing a hidden part of a window during two-pass color reduction
|
|
of the image in that window would abort the quantization. This was
|
|
particularly bad when doing the color reduction during a save.
|
|
|
|
(b1) Somehow, bundle bits in the Finder were not set on the version
|
|
3.2.1 I released; this is now done explicitly during the build. In
|
|
addition to the bundle bit, the shared bit is now set so multiple copies
|
|
of JPEGView can be run from a single copy on a server.
|
|
|
|
(b1) There was a conflict between the "always require bitmaps"
|
|
preference option and the "no bitmaps for uncompressed images" option --
|
|
that is, JPEGView would complain it didn't have enough memory to make a
|
|
bitmap for an uncompressed image, because you told it not to :-)
|
|
|
|
(b1) If you had selected a slide show folder that was on a removable
|
|
medium, JPEGView would prompt you to insert that disk everytime you
|
|
started up. JPEGView now does a less-intrusive check for the existence
|
|
of the last slide show folder you chose, and if it doesn't find it, it
|
|
resets the path to point to the Desktop.
|
|
|
|
(b1) Some people were detecting a write to memory location 0 when
|
|
quitting JPEGView.
|
|
|
|
(b1) The QuickTime VM patch would sometimes be incorrectly installed on
|
|
machines that didn't need it, resulting in a significant slowdown.
|
|
|
|
(b1) When scaling really large images (>1000 pixels in both dimensions)
|
|
down to icon size, the very high quality drawing (which I use for making
|
|
the icons) would sometimes crap out and not draw anything. This was due
|
|
to the fact that when a large number of pixels in the source image
|
|
contribute to a single pixel in the destination, each pixel's contribution
|
|
could end up rounding down to 0, since I only kept track of things to
|
|
1/1024th of a pixel. I have since modified the very high quality drawing
|
|
to retain resolution down to 1/65536th of a pixel, which appears to solve
|
|
this problem for the most part.
|
|
|
|
(b1) The Select Screen Area command would not be available if an image
|
|
that would have fit in a full screen window was instead being displayed
|
|
scaled in a normal window.
|
|
|
|
(b1) Printing images to the LaserWriter 8.1.1 driver seemed to go awry
|
|
somewhere along the line. This appears to be gone with the new
|
|
implementation of the QuickTime VM patch.
|
|
|
|
------------
|
|
Interim bugs
|
|
------------
|
|
|
|
(fc1, introduced in b1) Dragging a selection so the cursor was outside
|
|
the image rectangle would cause an unimplemented trap error, because I
|
|
was failing to check for the Drag Manager ahead of time.
|
|
|
|
(b5, introduced in b3) The JPEGView JFIF Preview wasn't displaying
|
|
previews properly for files with type 'JPEG'. Files with type 'JFIF'
|
|
were working all right, though.
|
|
|
|
(b2, introduced in b1) Fixed high quality drawing on the PowerPC.
|
|
|
|
--------
|
|
Features
|
|
--------
|
|
|
|
(fc1) The comments and statistics text can now be dragged out of
|
|
JPEGView and into another application.
|
|
|
|
(fc1) Progress dialogs and displays are updated more frequently now.
|
|
|
|
(b5) A variant of the Independent JPEG Group's JPEG decompression code
|
|
has been added as an alternative to using QuickTime for displaying
|
|
JFIF images. The IJG code is much more robust at error handling than
|
|
the QuickTime code, but is considerably slower on 680x0 machines. For
|
|
this reason, QuickTime is still the default for 680x0 machines, while
|
|
the IJG code is used automatically on PowerPC machines. If QuickTime
|
|
is not installed in the system, then the IJG code will automatically be
|
|
used on either system. User control over which code to use can be
|
|
found in the Miscellany section of the Preferences, at the bottom.
|
|
|
|
(b3) A new preference has been added: icon styles, under the "Files"
|
|
section of the preferences. This allows you to choose one of four preview
|
|
icon styles: square or proportional (a la Photoshop), with or without
|
|
"dog ears". Hopefully that will be enough to please most everyone.
|
|
|
|
(b3) The scale AppleScript property of an image now accepts integers
|
|
from 1-100 instead of fixed point numbers which AppleScript doesn't know
|
|
how to deal with.
|
|
|
|
(b2) The File Format popup menu is no longer displayed if you are saving
|
|
a non-JPEG image. Hopefully this will stop people asking me for an
|
|
"unlocked version" which supports this. :-)
|
|
|
|
(b2) Added a new mini-popup menu to the bottom of the save dialog which
|
|
lets you do something with the currently selected area of the image
|
|
you're saving. The options are: do nothing, use selected area to
|
|
specify the icon cropping (it still has to be square for now, though),
|
|
or use selected area to specify image cropping.
|
|
|
|
(b1) After toying with a version of what I considered to be "low" quality
|
|
drawing (i.e., really fast but pretty crummy), I discovered that my low
|
|
quality was actually equivalent to my high quality in 95% of the cases.
|
|
With that knowledge in hand, I rewrote high quality drawing to do "low"
|
|
quality drawing instead, and came up with a good 20-75% speed increase
|
|
(you'll a see 5-25% increase overall, including decompression) with very
|
|
little additional quality loss. The high quality dithering is still
|
|
included, so it will continue to be labelled "high" quality, despite the
|
|
fact that the scaling quality isn't quite on par with Color QuickDraw's.
|
|
|
|
(b1) Due to the above change, the default drawing quality is now set to
|
|
"very high".
|
|
|
|
(b1) Display times in the statistics floating window are now given to
|
|
the 1/100th of a second. I was mainly using this for PowerPC
|
|
benchmarking, and may decide not to keep it in for good.
|
|
|
|
(b1) On a drag-aware system (that is, with the Macintosh Drag and Drop
|
|
extension *and* a drag-aware Finder -- e.g., a Mac with system 7.1.2 and
|
|
the extension), you can now drag any folder or disk icon from the Finder
|
|
into the slide show options window to set the slide show folder (very
|
|
cool :-).
|
|
|
|
(b1) Dragging a selection outside of its window will, on Drag-aware
|
|
systems, allow you to drag and drop portions of an image into other
|
|
apps, or into clippings files in the Finder.
|
|
|
|
(b1) Updated the operation and use of the internal QuickTime VM patch, so
|
|
that it now allows the use of up to 512k of temporary memory for image
|
|
decompression. Its effects are also now disabled before giving time
|
|
to other applications so that extensions that need to use temporary
|
|
memory can still do their thing.
|
|
|
|
(b1) Opening PICTs at other than 72dpi now expands them to the full
|
|
resolution.
|
|
|
|
(b1) The "marching ants" used to indicate a selection have been redone
|
|
completely, and are no longer rendered invisible in medium-gray areas of
|
|
images.
|
|
|
|
(b1) Once you've cropped an image, you are now allowed to save it; when
|
|
you do this, however, what you are actually saving is not the cropped
|
|
image alone, but rather the entire original image plus a 'RECT'
|
|
resource which specifies the initial cropping. Thus, images may be
|
|
cropped for better viewing, but may always be recovered.
|
|
|
|
|
|
=================================
|
|
Remaining "bugs" for JPEGView 3.3
|
|
=================================
|
|
|
|
----
|
|
Bugs
|
|
----
|
|
|
|
(?) Statistics for cropped images saved with previous versions are
|
|
messed up.
|
|
|
|
(?) The JPEGView Convert To PICT script saves palettes for grayscale
|
|
JFIFs.
|
|
|
|
(?) JPEGView's progress window can poke through the Finder's window when
|
|
running in the background.
|
|
|
|
(?) Dragging windows from 1-bit screens to deeper screens doesn't always
|
|
force a complete redraw?
|
|
|
|
(?) I've had two reports of bugs when running a second slide show during
|
|
the same JPEGView session. As far as I can tell, it's linked to selecting
|
|
a different folder for the second show, but I can't reproduce the problem
|
|
at all.
|
|
|
|
--------
|
|
Features
|
|
--------
|
|
|
|
(?) Modify the way the slide show works internally to read any number of
|
|
aliases from the specified file. This is in anticipation of the future,
|
|
where we will store slide show information in a separate file, allowing
|
|
multiple files and/or folders. Although we will put in the code to
|
|
handle multiple entries and external files, 3.2.2 will always read from
|
|
the Preferences file, and will always find only one folder specified.
|
|
Consider it a step forward.
|
|
|
|
(future) More detailed preferences for specifying dithering, display
|
|
quality, and color reduction for each image depth. Something like
|
|
this:
|
|
|
|
When using... Reduce
|
|
colors? Dither? Quality?
|
|
16 colors x x normal v
|
|
256 colors x x very high v
|
|
Thousands x very high v
|
|
Millions very high v
|