Theres been some discussion about SVG support recently.
Im in the process of assembling icons for a new project and as usual always get disappointed by the results of scaling.
What Id like to do is include a vector image, and instead of putting a bitmap on the toolbar or button, instead render a scaled image.
I can’t seem to find a way to include a vector image from an external source any longer, given PICT is dead.
Is there any way to do this now?
PSD files abound on the internet but are no use here…
What platform do you develop for? For Mac OS X, you could use MacOSLib or another implementation of NSImage which has some intiwithPasteBoard methods that know how to handle EPS and PDF too (theoretically, havent checked that yet).
To avoid the bad scale effect you have to:
Use the images with the right size
or use monochrome icons built using a custom font (and again built with the right size)
If you are having problems with the quality of scaling on Windows, then this conversation might be helpful. It shows how to perform high quality scaling with the canvas control:
More that Im rubbish at drawing at that scale, and never happy with the results.
Im cross eyed looking for icons on the web, and usually find maybe 5 out of 16 that I need.
Trying to make the missing ones look consistent with the ones I like is almost impossible.
I suppose what I need is someone who can ‘do this stuff’, but Ive had some bad experiences of trying to contract this out in the past.
Think I know exactly what you mean. I recently came to a point where I liked the icons I created (Logoist is a really nice tool for that), but then I had to add another one and could use of the system icons for that. Damn, it looks much crisper!
Therefore: Yes, vectors please! I found vectorstock.com to be a great resource, especially because you usually find complete icon sets that share the same style, but taking the vectors to create pixel images in different sizes is a bit annyoing.
I am not quite sure vector support would solve the issue of inherently poor resolution. I have worked for years with fonts, which are originally vectors, and their poor rendition on 72 dpi screens.
At 12 points, a character displays on something like an 11x11 pixels matrix. Anything else than vertical and horizontal lines will look jagged.
With 32x32 or 48x48 pictures, the problem is similar. No matter the kind of vector technology used, it will always land on a matrix of pixels. Same thing for larger pictures shrunk to size. Anti aliasing can somehow alleviate the jaggies, but at the price of crispness.
Commercial icons such as what Ulrich mentions are not the result of mechanical production, would that be vectors or larger images reduction. They have been drawn by artists who master contrast of color, optical illusion and other tricks that allow their work to both look crisp and not show jaggies.
Incidentally, that is the reason why simply reducing the size of a 1024x1024 icon is not possible beyond certain limits. No matter the quality of the original, it will always suck at 24x24 and under.
In some of my programs, I have redrawn the app icons for sizes 48 and under, so they look better at these sizes. Only through a patient manual process could the best effect be reached.
Youre completely right. Thats why early PostScript fonts introduced hinting to give the RIPs better methods to preserve readability for smaller sizes. Lines would have to be strengthened if they would drop below 1 px (or more) on the output device. In essential there is a low-res description in them too.
And then there were the times before what was its name Adobe Type Manager? when we had to carry a lot of bitmap fonts in our suitcases so the screen display could be called WYSIWYG.
[quote=125022:@Ulrich Bogun]Youre completely right. Thats why early PostScript fonts introduced hinting to give the RIPs better methods to preserve readability for smaller sizes. Lines would have to be strengthened if they would drop below 1 px (or more) on the output device. In essential there is a low-res description in them too.
And then there were the times before what was its name Adobe Type Manager? when we had to carry a lot of bitmap fonts in our suitcases so the screen display could be called WYSIWYG.[/quote]
In the late 1990s I had a special order from a customer who needed a font with exactly the same rendition on Mac and Windows. Vector was not precise enough to achieve that. The only way to do it was with bitmap fonts.
Not long ago, when the issue of the caret being off in the Xojo IDE because character width is fractional and errors accumulate https://forum.xojo.com/13571-caret-issues I tried to devise an OpenType font that would generate precise pixels values. I was never able to do it. Internal font precision is far, far beyond the 11 pixels, so it should have been possible. Yet, because ultimately the font imager extrapolates the pixel rendition from the vector data, quantum effects occur where the imager may decide on adding or not a pixel on the flip of a coin : what do you do when the width of a character is 11.50 pixels ? Seems the answer is not quite straightforward. Only a bitmap font could solve the issue, but Cocoa has disposed of such technology …
I second the usage of PDF on OS X via NSImage (MacOSLib, MBS or Retina Kit). In fact Apple are encouraging the use of single color vector PDF images, mainly to help with the new visual styles of Yosemite, but also for resolution independence (because the graphic has no DPI).
With NSImage you can simply open a PDF image and draw it, or attach to a NSView
For Xplat and Web, low weight, easy to handle vectors, types and compound shapes, tag-able, better for save/load and handling internal parts, I still stick with SVG (and SVGZ for compressed size). For your precise problem, handling PDF on OSX for a simple scalable image, check this http://b2cloud.com.au/how-to-guides/scalable-ios-graphics-pdfimage-framework/
