Help identifying an OLD font?

[TerraHertz]

You can scale vector graphics as you please.
Zoom in on the penguin (and letters), it stays all pretty. A raster image, such as PNG would get pixelated.

Did you assume I didn't know that? Good grief...
My question should have been, who cares? It's a web graphic, of no particular importance either intrinsic or historical. Scaling it down, it stays fine. Up, for huge displays... Hmm, complaining about pixelation in that case seems to me like the visual equivalent of audiophoolery. Perfectionism for no practical benefit.

As opposed to attempting to accurately represent some media of actual historical interest, where there's a duty to have the electronic representation faithfully reproduce what the eye would see when looking at the original media from long ago.
But if you zoomed right in on the original media, you'd see ink on paper irregularities, or image screening dots. So what's wrong with seeing pixelation on a digitally created image? It's a perfectly valid artistic choice, to allow pixelation as an intrinsic feature of the work. Of course it's also a valid choice to spend a lot of time creating an infinitely zoomable vector-based image.

[Nominal Animal]

So what's wrong with seeing pixelation on a digitally created image? It's a perfectly valid artistic choice, to allow pixelation as an intrinsic feature of the work.

Like I mentioned, I don't like the scaling effects.  It's not just pixelation: browsers use nearest-neighbor scaling, which introduces defects that poke me in the eye.

Of course it's also a valid choice to spend a lot of time creating an infinitely zoomable vector-based image.

Huh?   For me, it was definitely faster to do Tux in Inkscape, than it would've been in Gimp or Photoshop.

I am not a graphic artist, but I do have done that work, too.  For example, in 1997 I created the very first set of collector cards for the Finnish Defence Forces; purely PR stuff.  Used a classic Mac for that: Photoshop (4.0, IIRC) for the photo editing and touchups, Macromedia Freehand (7.0, IIRC) for the layout and diagrams and text on the backside.

Do note that the SVG stuff is just 90k or so, and it is already loaded when the page loads; no separate TCP connection for the image.  That means it loads faster than if the image was in a separate file.  All in all, incorporating SVG into the HTML is simply superior to using a JPEG or PNG image instead, for this kind of content.  Photos are a completely different matter, of course.

If I would get off my butt and implement it, I could make Tux have Crazy Eyes, following the mouse cursor, with just a few lines of Javascript on top.

[tooki]

You can scale vector graphics as you please.
Zoom in on the penguin (and letters), it stays all pretty. A raster image, such as PNG would get pixelated.

Did you assume I didn't know that? Good grief...
My question should have been, who cares? It's a web graphic, of no particular importance either intrinsic or historical. Scaling it down, it stays fine. Up, for huge displays... Hmm, complaining about pixelation in that case seems to me like the visual equivalent of audiophoolery. Perfectionism for no practical benefit.

That SVG is small, and as he said, embedded in the HTML so loads super fast. A PNG large enough to look good on large high-res displays (like 4K) would be much larger, and shrinking that down on smaller displays would mean much more “wasted” data — and for an inferior result!

So what's wrong with seeing pixelation on a digitally created image? It's a perfectly valid artistic choice, to allow pixelation as an intrinsic feature of the work.

Like I mentioned, I don't like the scaling effects.  It's not just pixelation: browsers use nearest-neighbor scaling, which introduces defects that poke me in the eye.

No they don’t, and haven’t for many years — unless you specifically ask for it with the image-rendering: pixelated CSS style.

[amyk]

That SVG is small

SVG is one of the worst vector graphics formats around. It's like they wanted to XML-ize everything, but that would be even more bloated, so ended up sticking PostScript/PDF-ish commands inside XML elements. A SWF of the same content would probably be 1/10th the size.

[Nominal Animal]

Like I mentioned, I don't like the scaling effects.  It's not just pixelation: browsers use nearest-neighbor scaling, which introduces defects that poke me in the eye.

No they don’t, and haven’t for many years — unless you specifically ask for it with the image-rendering: pixelated CSS style.

You're right; I should've written "used", when I first started doing this in 2008 or so, and some still did when I created my version of Tux in SVG a few years back. 

(In 2008, I had to embed the SVG, have a VML fallback if SVG is not supported, and a PNG/JPEG/GIF backup if that is not supported either.  It wasn't fun to do as it needed a lot of hand-fixing details, but the results were much superior to just using an image.  Did that for an Uni department, for the logo.)

While SVG is quite verbose, it is a format you can produce from any programming language – and I often write helper scripts to blurt out SVG images of 3D shapes I'm interested in –, including Javascript; and when incorporated in the HTML, you can modify the SVG just as easily as you can modify HTML elements, for animation and such.  It itself is a compromise, so not optimal for any particular purpose, but for purposes of the web, as a vector graphics interchange format, it works damn well.  The other alternatives (VML, PGML) were worse.  (My own machine doesn't have software to play/display SWF at all – I don't need or want the security holes –, and claiming SWF is better is just silly.)

I am surprised by the objections to using SVG.  Interesting.

[tooki]

That SVG is small

SVG is one of the worst vector graphics formats around. It's like they wanted to XML-ize everything, but that would be even more bloated, so ended up sticking PostScript/PDF-ish commands inside XML elements. A SWF of the same content would probably be 1/10th the size.

That may well be, I’ve never compared the efficiency of different vector formats. By “small”, I meant that by the standards of the modern web and Internet connection speeds, it’s not a lot of data in absolute terms. (And by being embedded, it saves tons of handshaking to open more connections to download an external file.)

[tooki]

Like I mentioned, I don't like the scaling effects.  It's not just pixelation: browsers use nearest-neighbor scaling, which introduces defects that poke me in the eye.

No they don’t, and haven’t for many years — unless you specifically ask for it with the image-rendering: pixelated CSS style.

You're right; I should've written "used", when I first started doing this in 2008 or so, and some still did when I created my version of Tux in SVG a few years back. 

(In 2008, I had to embed the SVG, have a VML fallback if SVG is not supported, and a PNG/JPEG/GIF backup if that is not supported either.  It wasn't fun to do as it needed a lot of hand-fixing details, but the results were much superior to just using an image.  Did that for an Uni department, for the logo.)

While SVG is quite verbose, it is a format you can produce from any programming language – and I often write helper scripts to blurt out SVG images of 3D shapes I'm interested in –, including Javascript; and when incorporated in the HTML, you can modify the SVG just as easily as you can modify HTML elements, for animation and such.  It itself is a compromise, so not optimal for any particular purpose, but for purposes of the web, as a vector graphics interchange format, it works damn well.  The other alternatives (VML, PGML) were worse.  (My own machine doesn't have software to play/display SWF at all – I don't need or want the security holes –, and claiming SWF is better is just silly.)

I am surprised by the objections to using SVG.  Interesting.

It is interesting indeed. With that said, I suspect that billions of people are SVG graphics on webpages all the time without realizing it.

The other vector graphics format on the web, one which is undoubtedly far more widespread, is web fonts. Those are, after all, just collections of vector graphics (with some specialized commands embedded). What’s less commonly known is that custom web fonts are frequently used to store small vector graphics. Think of things like company logos, the little envelope next to email addresses, etc.

[whisky]

You’re totally right, about SVG (and support situation on browsers since 2014), SVG is a full part of any DOM element.

Just afraid that @amyk remark on PDF will @Terahertz disregard it :-)

Let say it’s not as bad as PDF, and definitely something that could be ‘generated/synthized’ by programs.

Note that it could also by scripted and styled inside the DOM, but we are now far from the original vintage and preservation intention :-)

[TerraHertz]

This is all very interesting. I'm still intending to learn more about SVG and related tools. Btw Nominal Animal, yes, I'm aware of the irony of my questioning desire for perfection, in a thread about my seeking perfection with an obscure font for an antique pressure gauge.

@Whisky  The ability to script vector-based web graphics via JS/DOM, is what interests me in SVG.

Just popped in here to mention that work on the gauge & regulator is slowed way down, due to a sudden urgent task. That big milling machine. https://www.eevblog.com/forum/chat/what-did-you-buy-today-post-your-latest-purchase!/msg3095089/#msg3095089
I'm hoping to move it this coming week.

[Nominal Animal]

Btw Nominal Animal, yes, I'm aware of the irony

No, I didn't mean "I find it ironic...", I literally meant I found the objections interesting.  I definitely wasn't implying irony or such.

The ability to script vector-based web graphics via JS/DOM, is what interests me in SVG.

It is extremely useful; for example, if you wanted to make an oscilloscope-like graph on a web page, you can do it all on the client (browser) side, with the server/data source only providing the samples.  There are lots of tricks on that to make it efficient even on slowish single-board computers, like dividing a scrolling graph into blocks where only the latest block is modified, and most of the graph blocks just move, so that the display hardware does most of the work, and the CPU only has to render the still-mutating block.

Or you can do things like diagrams and maps interactively, with not that much Javascript needed.  (I've been waiting for a true client-side non-Java/non-Flash concept map editor to be developed...) If you are crafty about it, you can even make them 3D (even though SVG is strictly 2D), by considering all modifications to apply to a fixed z plane, and only worry about the 3D when rotating or scaling/zooming the view.