On 2006-08-05 at 16:51:21 [+0200], Simon Taylor <simontaylor1@xxxxxxxxxxxx>
wrote:
>
> > > Maybe you could define the path width differently, or have a weight for
> > > paths so that they don't reduce so much in smaller renderings. Dunno -
> > > using the Level Of Detail filter should work, too, of course.
> >
> > Yeah, I will try a couple of these things. Thanks for the comments!
>
> I think having another attribute in the Stroke transformer for "minimum
> width" (and maybe "maximum width" too) would work quite nicely. I tried
> with your demo text icon, and with the outlines set to width 4 they look
> quite nice at 16x16. I used a LOD filter to only have them that width at <
> 0.33 but obviously there is still a step change at a certain size from one
> to the other. It would be nice if the line could just get thinner until it
> hits the minimum size.
>
> Or maybe the line width could changed smoothly for all sizes - my absolute
> favourite outline widths were 2ish for the 64x64, 3 for the 32x32 and 4 for
> the 16x16. Perhaps "Width at 64x64" and "Width at 16x16" parameters would
> work nicely - then the stroke only needs 1 more parameter (which maybe
> could be left out of the flat representation altogether if width_64 ==
> width_16).
>
> Whilst playing a bit I've noticed a few bugs in Icon-O-Matic but you've
> probably fixed many of them already. I might try to Jam myself a fresh one
> for an R5 target, but I've never really understood the whole jamming thing!
To jam Icon-O-Matic:
cd into icon-o-matic folder
TARGET_PLATFORM=r5 jam -q
You can replace "r5" with "bone" (or "haiku") and "-q" is so that it stops
compiling as soon as it hits an error. You see from the Terminal output where
the resulting executable is located.
----
About the width thing. I have originally thought to provide some kind of
"hinting" (alignment to pixels) feature like it is done for font rendering.
The problem is that my current implementation ("Rounding" flag of shapes)
sucks.
You might have noticed the "Transformer" pipline in the Shapes (I mean how it
works in the code). For example, there is a way for the transformer pipeline
to tell to the shape if paths should be "closed" or not. When rendering at
the final stage, polygons are always closed, independent of the user setting
"Closed" for a given path object in the UI. The Stroke Transformer prefers
the polygons of the previous pipeline stage to stay "open" though. So that
you can have open outlines. Now for the "Pixel alignement" feature to become
useful, it needs to be integrated with the Transformer pipeline, much in the
same way that "wants open paths" works now. Then it would be easy to have the
stroke width depend on the global scale without the user having to worry too
much about it.
All this would work nicely together with your idea to provide a "width/global
scale ratio" in the Stroke Transformer. At least, this feature would need the
extension to the pipeline interface I outlined above. Thanks for your
comments! :-)
Best regards,
-Stephan