I will try. Actually, when I read the first post you did, I thought, Uhhh, I can use that. Thanks You!

Well, if you create something original, I'd say, let us see what you come up with!

is there anything like that for mac?

Not by me :-)

Answers to the original question (here) focused on ASCII art, which is definitely something else. As no-one seemed to know how to do it, I made it myself.

Perhaps a Mac based typographer cum programmer would like to jump in here.

Nice job, Theunis — looks great. I had an idea for some ways to do this when I saw your original thread, but didn't (and still don't) have the time to play around with it.

If you're amenable to opening up your source code, I might be able to build a Mac version. I'm familiar with FreeType and a few programming languages. Not necessarily fluent but maybe enough to port...

Josh,

Thanks for the offer! But I'm not quite there yet :-)
Yesterday, I added a single line (okay, maybe 2) and the justification was spot on (now it isn't) AND it's +/- 20% faster ... So, still tinkering. I'm considering changing the justify routine altogether, as it's now held together by spit and tape.

This version doesn't use FreeType at all, so a straightforward port to Mac could be a major pain, because the initial measurements are done with pure Windows calls. On the other hand, after that it's number crunching time, so ... perhaps ...

But, as I said, it's not quite fully developed. I still have some novel ideas -- I wonder how good it can get.

Well, if/when you get to a state where you are comfortable sharing, let me know. As I mentioned I don't really have the time to do something from scratch, but if it were possible to work from an existing code base would likely spare some development time. This is something interesting and fun.

It may or may not be an issue that your measurements, etc. are done purely with Windows calls for the font metrics and such...I could use the corresponding Mac OS system routines, or use FreeType, or if necessary read the font files directly. Which programming language is this written in?

Josh

The reason my first tries were with FreeType is because I'm not that comfortable with win coding :-) and I'm still developing some FreeType skills. It was pretty easy to write a proof of concept, though.
Then I realized I couldn't create a vector image that way -- only pixel based, and that was a real drag.

So I switched to pure Windows, using its native print routines. It turned out to have its own weird stuff. D'ya know that if you select a printer, you're stuck with its resolution, in integers only? So using floating point coordinates is off ... Also, it's impossible to scale a font to non-integer sizes! And I'm having a hard time getting relevant font data from this cursed system :-) So much for Myriad Pro Semibold at 8.5 pts; Windows doesn't allow either! At best, it explains some of Word's intricacies.

That's the Bad & Ugly news. Good news is that the hard work can be done (I think) in your programming language of choice -- given that you have (a) an image to sample, (b) an array of fonts and sizes (with access to their metrics on a character basis), (c) a large chunk of filler text, and (d) the dimensions and a pointer to some 'canvas' to write the results to. My version is in plain C, but the logic in the hard work loop should be portable enough. Originally, I was considering a PostScript version -- now that would be something! (drool) (okay, not now)

Your website doesn't mention contact details, but you can reach me through my domain, using my first name as e-mail address. Intentionally oblique, to fool spambots ... (God, how I hate spam! Don't get me started on that.)

Theunis this is awesome, you have no idea how many hours you just saved me in a project I am doing at the moment. Big ups

-Rafe

Theunis, I was wondering whether you take into account the exact font metrics, what I mean whether you calculate the area occupied by the black of the glyph vs. the bounding rectangle? (If you have five weights 1...superlight 5...superbold) it might happen, that in a font weight 3 m is darker in tone than a weight 4 n e.g., especially in monowidth fonts).

An excellent observation!
No, I don't do that. That means that the "distance" in gray between, say, 4 pt Arial and 5 pt Arial and 6 pt Arial is the same for each. As characters are square objects, this should be a logarithmic difference instead (?? -- pretty sure about that...).

You can influence this by eyeballing it with the Curves option, but I think I know how to make it more "exact" (read: "less inexact"). It's not the bounding box, because this has the same black-to-white ration for each of the different sizes :-) Instead, I should check against the coverage of each size against the total line height of the line -- that is, the height of the biggest font size. So a 4 pt Arial Black is much lighter than a 12 pt Univers Light, on a line heigth of 12 pts.

The actual gray values are not that important, though. What's more important is the different ratio from one level to another, those you can now set manually. That should/could be an automatic setting.

Ouch. I don't know how I could be so unattentive. I believed you used different _weights_ of the font, not different _sizes_. I guess, I did not look at the pictures, but only remembered your sentence in the original topic (using the word "weight").
I thought you were using the same font in ultra-light, light, medium, black, ultrablack or something like that. Sorry for the misunderstanding.

I really should have looked more carefully.

No need for apologies! It works just as fine with different weights. Or even different fonts (although you're on your own for selecting the gray values).

I just finished adding a few interface niceties: a Save and a Load button, so you can save (and load) the font list. You can also manage the list itself, moving stuff up and down and editing with a quick double-flick on the font name. You can save the settings as "defaults.fis", which will set the defaults (...).

This version has a different name: somewhat more appropriate, FontImage. I noticed "TextImage" was already used for ASCII art apps, this is definitely something else :-) (Thanks to Tim Satink for that name.)

The new version, again available at my site (direct link), features a slightly faster printing and better justification. Some bugs included -- still no guarantees.