Forums > MaxMSP

native font rendering

May 24, 2008 | 12:21 am

Here are a couple of screen shots showing comparisons between the current Max 5 font rendering and our forthcoming native font rendering feature. The image of the tempo.help file (imported from 4.6) on the left is JUCE font rendering, and the image on the right is platform-native font rendering.

http://www.cycling74.com/download/font_comparison_mac.png

http://www.cycling74.com/download/font_comparison_win.png

Since you will be able to turn native font rendering on and off, there’s no need to complain about the rendering of a particular platform, or differences between platforms. Everyone will have an opinion about what they like better, and you can find lots of discussions on the internet about the relative merits of each platform’s approach to fonts. But your friends at Cycling ’74 would like to get on with worrying about more important things now.

This stuff will be going into testing early next week. I suspect that may take a while, but we’ll release an update with this new feature within the next few weeks.

David Z.


May 24, 2008 | 2:43 am

Wow!
Much much much better, thank you for your efforts!!!

————– Original message ———————-
From: David Zicarelli
>
> Here are a couple of screen shots showing comparisons between the current Max 5
> font rendering and our forthcoming native font rendering feature. The image of
> the tempo.help file (imported from 4.6) on the left is JUCE font rendering, and
> the image on the right is platform-native font rendering.
>
> http://www.cycling74.com/download/font_comparison_mac.png
>
> http://www.cycling74.com/download/font_comparison_win.png
>
> Since you will be able to turn native font rendering on and off, there’s no need
> to complain about the rendering of a particular platform, or differences between
> platforms. Everyone will have an opinion about what they like better, and you
> can find lots of discussions on the internet about the relative merits of each
> platform’s approach to fonts. But your friends at Cycling ’74 would like to get
> on with worrying about more important things now.
>
> This stuff will be going into testing early next week. I suspect that may take a
> while, but we’ll release an update with this new feature within the next few
> weeks.
>
> David Z.
>
>


May 24, 2008 | 4:18 am

Awesome, looks much better to me! Thanks for the great efforts on this
and the quick response.


May 24, 2008 | 7:48 am

David Zicarelli schrieb:
> Here are a couple of screen shots showing comparisons between the
> current Max 5 font rendering and our forthcoming native font
> rendering feature. The image of the tempo.help file (imported from
> 4.6) on the left is JUCE font rendering, and the image on the right
> is platform-native font rendering.
>
> http://www.cycling74.com/download/font_comparison_mac.png
>
> http://www.cycling74.com/download/font_comparison_win.png

Only the layout between Max and Win isn’t the same anymore. Look at the
comment on the left, above the tempo message. The Win rendering needs
more space and looks even better than the Mac rendering. (The text is
more colourful somehow, I see some red…)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


May 24, 2008 | 10:07 am

As I understand it, that is the point.

If you want identical layout cross-platform, you’ll have to use the JUCE rendering option (or whatever they end up calling it). The price is the somewhat fuzzy (for lack of a better term) look.

To get the sharper "native rendering" look, you’ve got, um, native rendering.-

I don’t know how Adobe manages their cross-platform text rendering, but I expect that if it were easy, everybody would be doing it. And I’ll leave it to others to decide if they think it’s better, worse, or indifferent.

What I would be interested to know is if the rendering option will be a global option or something set on a patcher-by-patcher basis. Stuff like .maxhelp files will probably do better with JUCE rendering. (Selfishly, I’m thinking about Litter and iCE.) For my own performance/installation projects, which almost never have to switch platform, I’d like to make use of native rendering. And, of course, I’d prefer not to have to manually switch options a dozen times a day.

As long as this is a work in progress, I hope it’s fair game to ask where the option is going to land.

– P.


May 24, 2008 | 10:22 am

On 24 May 2008, at 01:21, David Zicarelli wrote:

> Since you will be able to turn native font rendering on and off,
> there’s no need to complain about the rendering of a particular
> platform, or differences between platforms.

Ah – I was going to ask whether it would be handled like that.

Is the native rendering setting saved with each patcher (as an
attribute)?

– N.

Nick Rothwell / Cassiel.com Limited
http://www.cassiel.com
http://www.myspace.com/cassieldotcom
http://www.last.fm/music/cassiel
http://www.reverbnation.com/cassiel
http://www.linkedin.com/in/cassiel
http://www.loadbang.net


May 24, 2008 | 5:27 pm

The font rendering choice is global, and we’re not even going to entertain any other possibility. Peter, is there actually any important effective difference in the layout of the help files based on the difference in font rendering? No there is not. Also note that the differences diminish as font sizes become larger. We no longer make help files at 9 pt and I suggest you consider doing the same.

Stefan I hope someday you can face the fact that there is a limit to what any sane and rational computer programmer can to do eliminate all differences between platforms, however minute. When C74 encounters engineering challenges that force us to choose between better experiences on an individual platform and cross-platform difference minimization, we try to choose the former, which is precisely why we’ve spent so much time worrying about fonts for the past couple of weeks. But, unlike Adobe, our core business does not involve selling things that draw text, so we have no intention to develop our own cross-platform font rendering engine. If this subject is of great concern to you, it might help to learn more about the subject. This article might be a good place to start.

http://www.codinghorror.com/blog/archives/000885.html

The blog comments illustrate exactly why I have already learned way too much about this stupid problem and cannot wait to forget it all.

David Z.


May 24, 2008 | 7:17 pm

David Zicarelli schrieb:
> Peter, is there actually any important effective difference in the
> layout of the help files based on the difference in font rendering?
> No there is not.

I don’t think it is important at all, but the pictures showed a
difference in the layout. I consider have a new line after "send" or
after "floating" a difference in layout… But nothing to worry about
too much, I do prefer the better readability…

> Also note that the differences diminish as font sizes become larger.
> We no longer make help files at 9 pt and I suggest you consider
> doing the same.

This is the most important point for me, to accept anything you decide
with these issues. As I mentioned already about the blurriness. I would
anyway change to bigger font sizes…

> Stefan I hope someday you can face the fact that there is a limit to
> what any sane and rational computer programmer can to do eliminate
> all differences between platforms, however minute. When C74
> encounters engineering challenges that force us to choose between
> better experiences on an individual platform and cross-platform
> difference minimization, we try to choose the former, which is
> precisely why we’ve spent so much time worrying about fonts for the
> past couple of weeks.

I do appreciate your efforts a lot. The blurriness wasn’t even a big
concern for me personally, I loved the fact that the patches where the
same cross platform…

> If this subject is of great concern to you, it might help to learn
> more about the subject. This article might be a good place to start.
>
> http://www.codinghorror.com/blog/archives/000885.html

Thanks for the link, interesting insights, though the subject is not of
too great concern, I did read and found that my observation that a pixel
grid related kerning would solve the problem was correct. But What I do
not understand why the same technique would create different results on
different platforms, as I understood, with juce you are not using the
platform native rendering, and a pixel is a pixel be it Windows or OS X,
maybe its because of 64-bit rounding… ;-)

Have a nice weekend and pause a bit, you deserve it…

All the best,

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


May 24, 2008 | 10:09 pm

Quote: David Zicarelli wrote on Sat, 24 May 2008 19:27
—————————————————-
Peter, is there actually any important effective difference in the layout of the help files based on the difference in font rendering?
—————————————————-

The screen shots showed different line breaks depending on the rendering model. Different line breaks can result in different numbers of line per box. That can lead to boxes overlapping.

The native font rendering looks really excellent in the screen shots, I think it’s a great development, and I’m glad that I don’t have to actually program this stuff. Seems I wasn’t the only person to want to know if it would be global or a patcher attribute. Now we know.


May 24, 2008 | 11:48 pm

Wow… Thats quite the turnaround. I didn’t realize it was such a big deal when I started the anti anti aliasing thread. but I appreciate your effort immensely. We all know what it’s like to get a suggestion which probably doesn’t fit nicely into the structure of your code.



mdk
May 25, 2008 | 3:14 pm

brilliant.

how refreshing to have a software company that listens AND acts.


Viewing 11 posts - 1 through 11 (of 11 total)