native font rendering

May 24, 2008 at 12:21am

native font rendering

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.

#38030
May 24, 2008 at 2:43am

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.
>
>

#131805
May 24, 2008 at 4:18am

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

#131806
May 24, 2008 at 7:48am

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

#131807
May 24, 2008 at 10:07am

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.

#131808
May 24, 2008 at 10:22am

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

#131809
May 24, 2008 at 5:27pm

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.

#131810
May 24, 2008 at 7:17pm

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

#131811
May 24, 2008 at 10:09pm

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.

#131812
May 24, 2008 at 11:48pm

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.

#131813
May 25, 2008 at 3:14pm

brilliant.

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

#131814

You must be logged in to reply to this topic.