Joined: Oct 31, 2005 Posts: 56 Location: Victoria BC Canada
Posted: Mon Sep 03, 2007 3:09 pm Post subject: OOo aqua project-no aesthetic Mac understanding
Regardless of what Eric Bachard and crew do to improve the Ooo Aqua, they have already implemented a strategy that is the kiss of death for knowledgable Mac users. It has to do with how they handle font families. They blend them so in the font list there is only one instance, e.g. Times New Roman, and one therefore has the ability to call the Bold and Italic weights by clicking on the B or I toolbar icons or using the keyboard equivalents. That’s fine if you have a font family that conforms to the Microsoft typography mediocrity of having Roman, Italic, Bold Italic and Bold weights/variants. Only a minority of real, typographically useful fonts follow this convention. Most elegant fonts from real type foundries such as ITC, Letraset, Bitstream, Adobe (the latter who licence many of their fonts from real font foundries). Such fonts never have the simple Roman, Italic, Bold Italic and Bold weight designations, they are more often likely to have more than four weights, with names like demi-bold, cursive, boldOSF [old style figures], black, black italic, ultra black, ornaments, [various weights of] condensed or expanded, etc., etc.
A short example: I have the font family Snell Roundhand installed; the weights are Black, Bold and Regular. If I call that font in Ooo, it defaults to Regular, and I can call the Bold variant, but not the Black, it simply is not available in the inadequate font family blending algorithms of Ooo.
By contrast, the NeoOffice font drop-down displays all weights and variants of a font family, so that if one wants other than bold or italic, e.g. ITC Garamond Light Condensed Italic, there it is in the menu. If one frequently used one of these ther-than-bold-italic fonts regularly, it is theoretically possible in Ooo to construct it as a Style. In the Style modification box when one clicks on ITC Garamond, on the right is a list of 6 sub-family weights. The trouble is, Light Condensed Italic is not in the list, as it is truncated at 6 variants. And of course this means that large font families such as Minion, which has 31 weights/variants, the user has access only to 6 of these.
In NeoOffice, since the family variants aren’t blended, on the left-side list of the Styles creation box are shown all of the variants, and all that appears in the right-hand box is the specification built into that variant, i.e. in this case Light Italic. The only other word processor that appears to be able to make such a text style is MS Word, but there the fields are not wide enough, so the “ITC†at the beginning is not displayed, so that if one has other Garmond families installed, it can be hard to tell what font family you are accessing.
Thus NeoOffice does what the Mac has been renowned for since the beginning, and which has never been implemented correctly and with such elegance on any other platform. That is why starting in the early 1990s major newspapers tossed out their huge clunky electronic typesetting stations and installed a bunch of Macs networked over AppleTalk or EtherTalk. NeoOffice, because it is developed by Mac savvy people, has retained this elegance and resisted the Microsoft dumb-down metameme. I don’t know what Bachard uses normally, but if it is a Mac, he’s never grasped its typographic elegance, unless maybe in the area of math symbols for his physics work.
All the more reason for people not to be seduced by the Ooo Aqua project, which by the way is planning to drop support for PPC and develop only for Intel, and to de-emphasize English language specific ports, as (from his blog) Bachard opines that “My idea was to improve the readability: the first and urgent need is localize some parts, providing a link with Native Lang Community projects, (but not in english, because a lot of users don't understand -and will never- read english).†He’s fond of statistics like the declining number of PPC machines relative to Intel ones, and his projection is that by the end of 2007 PPC will represent only 10% of working Macs (but he conveniently neglects stats on the percentage of Mac users whose language is English). So, all you folks that throw in with Ooo Aqua and use PPC machines will find yourselves out in the cold by next year. Or, you can take your perfectly good PPC machine to the recycle depot and buy an Intel machine you' rather not afford just so you can keep up with Ooo Aqua updates.
Solution: help the Ooo people out with vigorous suggestions to improve their code base in Mac-favorable ways (I’m gonna bug hell out of ‘em about the font family blending), but save your donation money for sending to Planamesa.
The listing of only font families does seem like a bad implementation. What is sad is that even Apple's Java engineers made the same overly simplistic assumption that font families only have regular, bold, italic, and bold italic variants. As a result, NeoOffice has code to replace Java's overly simplistic Java-to-native font matching code.
As for dropping PowerPC suport, that just seems pointless. Sure, having two download links and having to do an extra build run on a PowerPC machine is a little extra work, but it only adds a very small amount.
To give you real data on how little PowerPC adds to our work, here's the work I do to spin and upload a patch on PowerPC: boot my PowerPC machine, ssh into it (as I'm too lazy to switch machines), execute cvs update and a make command, catch up on my e-mail in the minute or two it takes to build, ftp the test patch server.
In other words, my PowerPC machine is turned off almost all of the time except for the 5 minutes it takes to spin and upload a patch. That seems to be a very reasonable price to pay to be able to add support millions of PowerPC owners.
Joined: Oct 31, 2005 Posts: 56 Location: Victoria BC Canada
Posted: Tue Sep 04, 2007 12:32 am Post subject: There should be a blog...
Somebody closely enough associated with NeoOffice development to speak knowledgeably about what is going on under the hood should tackle the controversies that have arisen and the demonization of Planamesa. After all, that is what blogs are for, an emphasis on POV and opinion.
Quote:
NeoOffice has code to replace Java's overly simplistic Java-to-native font matching code.
That is a perfect example; one wouldn't have to go into the drawn out explanation I gave in my previous note, some screen shots of the font drop down in OOo Aqua vs that of NeoOffice would tell much of the tale.
Speaking of Java, does the OOo Aqua use it in a similar way to NeoOffice or is it pure Cocoa? I'm no techie but if they are leaving out Java (and one never knows what grief future iterations of Java might bring for Neo) so would it not be fair ball to capture their code from a CVS repository and improve upon it to have the best of both worlds, a non-Java dependent app suite and all the savvy of your prior development and Mac specific knowledge?
Joined: Feb 12, 2005 Posts: 607 Location: Australia
Posted: Tue Sep 04, 2007 3:48 am Post subject: Speed
FWIW, I tried OOoMac out today and, while it's flaky and unfinished and still full of old Windows/Linux stuff, it is also quite snappy. Loads up new document pages very quickly - and starts itself up quickly. Even opens long documents without undue delay. It's certainly much better than it was a month or so ago when I previously had a squizz* Couldn't comment on more technical aspects.
As for dropping PowerPC suport, that just seems pointless. Sure, having two download links and having to do an extra build run on a PowerPC machine is a little extra work, but it only adds a very small amount.
The OOo team also decided some time ago to arbitrarily cease supporting Mac OS X 10.3.9 in the OOo 2.x bugfix releases; thus 2.1 is the last release available for 10.3 users. It seems to be a tremendous burden to them to continue supporting anything they already supported (but maybe it's support in general they have a problem with, given Jake's go-round with user support with them?) I can see an argument for not making the Aqua snapshots run on 10.3 since it's entirely new code, but it says something about your organization and process when you can't maintain OS support through a series of bugfix releases....
It can't be that difficult; NeoOffice (a much smaller organization) has not suffered from these same flaws, as the entire 2.x series has run on 10.3 and 10.4 (and the later versions on 10.5 as well).
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Posted: Tue Sep 04, 2007 9:18 am Post subject: Re: There should be a blog...
[quote="vicjoe"]Somebody closely enough associated with NeoOffice development to speak knowledgeably about what is going on under the hood should tackle the controversies that have arisen and the demonization of Planamesa. After all, that is what blogs are for, an emphasis on POV and opinion.
Quote:
NeoOffice has code to replace Java's overly simplistic Java-to-native font matching code.
I used to care, but now I really don't. Why? Because despite all of the controversy that the OOo Aqua team tries to create, the NeoOffice user base and donor pool and support volunteers have all been increasing. This tells me that our work is addressing the needs of our users.
It took us several years to get all of the subtle little bugs ironed out but now we are able to focus on adding and improving features in NeoOffice instead of just worrying about making OOo run natively.
vicjoe wrote:
Speaking of Java, does the OOo Aqua use it in a similar way to NeoOffice or is it pure Cocoa? I'm no techie but if they are leaving out Java (and one never knows what grief future iterations of Java might bring for Neo) so would it not be fair ball to capture their code from a CVS repository and improve upon it to have the best of both worlds, a non-Java dependent app suite and all the savvy of your prior development and Mac specific knowledge?
They use pure Carbon. NeoOffice generally uses Java which is pure Cocoa.
As for lifting their code, we have done that for pieces of code that look solid and have little risk like the native Address Book code. However, while OOo Aqua has some speed due to its use of Carbon, they will run into many of the same performance bottlenecks that we ran into when we switched to Cocoa (Java 1.4.x and higher uses Cocoa to do its work).
Also, I suspect that some of the speed is due to OOo Aqua skiping critical steps. For example, try inputting Japanese text and you will note that OOo Aqua does no font fallback and you just get squares. This is fast, but ineffective.
Their code is very immature in that few people have actually tested it. In contrast, the NeoOffice code has had hundreds of thousands and maybe millions of people test each new feature and improvement. While many people think that the initial development is where the work is, my experience is that 80% of engineering time is spent debugging and fixing the corner case bugs that show up after you release new code. As such, using their code is not much different than starting over again.
Joined: Apr 25, 2006 Posts: 2315 Location: Montpellier, France
Posted: Tue Sep 04, 2007 9:32 am Post subject:
pluby wrote:
They use pure Carbon. NeoOffice generally uses Java which is pure Cocoa.
As I understand it, aquavcl01 is pure Carbon. But since WWDC, where they heard that Carbon may be dropped in 10.6, they freaked out and I think what they're trying to do now is to transition their Carbon code to Cocoa (that would be aquavcl02 and aquavcl03). But they will present a Carbon-only dev. snapshot dubbed "Barcelona" at OOoCon this year (intra-project marketing, IMHO).
Yes, the link in the latest OOo newsletter led to a blog (sorry, I don't have the link any more) which said something like 'download the snapshot binary (which is carbon) or download and build the bleeding edge version (which is cocoa)'.
Joined: Oct 31, 2005 Posts: 56 Location: Victoria BC Canada
Posted: Tue Sep 04, 2007 2:30 pm Post subject: Cocoa text system
Quote:
…the link in the latest OOo newsletter led to a blog…which said something like 'download the snapshot binary (which is carbon) or download and build the bleeding edge version (which is cocoa)'.
Well, it that is true and they (OOo Aqua developers) are taking a stab at Cocoa, it will be amusing to see them try to shoehorn the badly rendered font handling routines from their Carbon version into Cocoa, when ironically there is a ready-made set of modules for Cocoa, both native text and style handling. From the little I know of such things, though, it would mean massive backtracking and big changes to the UI to accommodate the Cocoa text system. Here is an interesting developer page that suggests some of the issues:
http://tinyurl.com/yrorvx
Though not the last word in text subtlety as Quark once was, it does honor all the basics, including font families unmerged and font metrics, kerning, leading, etc.
My guess is that if the Cocoa text system could have been integrated with the OOo code, Patrick and crew would already have done so. Their enhancement of the Java font routines is nothing short of brilliant.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Sep 04, 2007 8:56 pm Post subject: Re: Cocoa text system
vicjoe wrote:
My guess is that if the Cocoa text system could have been integrated with the OOo code, Patrick and crew would already have done so. Their enhancement of the Java font routines is nothing short of brilliant.
Less and less of our stuff is Java and more and more of it is Cocoa. If you look at our latest source code analysis (aside from the fact we're mostly C++) we have a strong portion of Obj-C in there, 2% of our code vs. 4% that is Java. Ever since Apple rewrote Java, we now use it just as a wrapper around Cooca, grab our NSWindows, and just go to town.
OOo also wants such low level control over fonts that it will never use an NSTextView for its core document rendering. That limits the amount of "free" font handling any OOo derivative can gain from Cocoa (except the toll-free bridged ObjC classes, but they're no different than their CoreFoundation counterparts).
Joined: Dec 08, 2005 Posts: 291 Location: Berlin, Germany
Posted: Tue Sep 04, 2007 10:16 pm Post subject: Re: Cocoa text system
OPENSTEP wrote:
OOo also wants such low level control over fonts that it will never use an NSTextView for its core document rendering. That limits the amount of "free" font handling any OOo derivative can gain from Cocoa (...).
I guess these are the pitfalls of cross-platform development: The powers to be at Sun, OO.org, Microsoft and other places who define (directly or indirectly) and influence the framework for OOo development never learned calligraphy, like his Steveness did, and therefore never developed a sense for text layout issues and typography. And it makes sense (sorry, vicjoe) in a certain perspective: I guess 95% of users (on all platforms) are as "typographically challenged" as them.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Sep 04, 2007 10:42 pm Post subject:
Obj-C is the future of Apple, as is Cocoa. Only applications written to make full use of Cocoa will get the benefits however; applications that seek the "lowest common denominator" will always be behind, whether they be written using StarView, Qt, GTK, Swing, (insert favorite framework here).
The logic is right. It makes developers really required to focus on Apple specific technologies to create a truly amazing Mac application.
An alternative operating system can only survive provided it has a self-sustaining ecosystem. This requires a distinctive user experience that can never be replicated by lowest common denominator cross platform frameworks and groupthink. Even Microsoft dropped the Universal solution, MFC for Mac, after the debacle that was Word 6. All Mac users hated it. MS themselves had to drink the koolaid to get a saleable product. Now MS Office is built using multiple Mac technologies and probably uses them even more extensively than Neo or OOo ever will.
As a developer, I wish Be had succeeded. That OS has the first multithreading friendly GUI APIs I ever saw and still has even the most recent Cocoa beat for threaded apps. In the current world of multicore their OS would have destroyed shop. The Be ecosystem of users and developers never became reality.
Joined: Oct 31, 2005 Posts: 56 Location: Victoria BC Canada
Posted: Wed Sep 05, 2007 1:18 am Post subject: the typography dumb-down
doctype wrote:
I guess these are the pitfalls of cross-platform development: The powers to be at Sun, OO.org, Microsoft and other places who define (directly or indirectly) and influence the framework for OOo development never learned calligraphy, like his Steveness did, and therefore never developed a sense for text layout issues and typography. And it makes sense (sorry, vicjoe) in a certain perspective: I guess 95% of users (on all platforms) are as "typographically challenged" as them.
This tendency, that we now widely refer to as “dumbing down” and of which typographic illiteracy is a good example, is one of my areas of interest. It is tied to the dominant ideologies in culture, particularly those driven by capitalist imperatives, but can be found in earlier commentaries, e.g. Nietzsche was among the first to trace the origins of the herd and the slave morality (mentality really). There's this phenomenon observed in evolution generally, called something like the rule of prior constraints, which was well-examined by Stephen J. Gould in his application of the Panda’s Thumb to technology, particularly to the creation of the QWERTY keyboard, which was a kludge compromise between producing manuscripts that were readable and limiting the number of keys to produce different characters and effects (and at the time, to intentionally slow the typist's speed so the mechanical character arms wouldn't get jammed).
Add to this the phenomenon of mass society, ultra-rapid development of communication technologies and you have a situation where complexities are managed by borrowing and/or retaining shortcuts from the past even when they are no longer expedient for the present. Thus in order to facilitate widespread adoption by the public of personal computers, the typewriter keyboard was retained, along with all the short-cut faux conventions such as inch/feet/hash marks for open and closed single and double quotes, underlining for emphasis. Thus the challenge in moving from typewriter to computer was minimized, and in the process brought along unanticipated habits like two spaces after a period or other full-stop character. That is one of the evolutionary responses to complexity, reversion to earlier stages of learning (as e.g. the 1st refrigerators sent by Western foreign aid to poor Asian countries were used as chicken coops). Such behavior is also more pronounced in mass society as people have unconscious resort to habit in order to manage input, the “great wheel of habit” as William James observed.
There is an equally powerful evolutionary adaptation mechanism that embraces manageable novelty and incorporates it, otherwise we wouldn't have all this technology, but it is a rather brute approach when the profit motive and associated compromises for the sake of competitive efficiency are dominant (and the impetus to artisanship is eschewed as ‘inefficient’).
Evolution both constrains (atavistic/throw-back) and elaborates (nascent/progress oriented) and the kinds of problem-solving orientations of social character are determined by the “Master Trends” dominant in the social structure. Both are at play as in the innovations being discussed in this thread, but the prior constraints seem to have the edge despite spectacular examples of overall advance and refinement.
The whole OOo approach is constrained by prior designs (that themselves were constrained by prior compromises), insofar as the goal was to make something that was familiar to MS Office users rather than striking out in a relatively unfamiliar direction as has been done with Apple’s Pages. The latter will always be a niche application used by a tiny minority, and unlike ClarisWorks, is unlikely even to be ported to any other platform.
I’m probably not making a lot of sense here, as it is a severe boil-down of many overlapping theories in sociology/social psychology, evolutionary theory, complexity theory, etc. such that my attempt to even suggest the factors going on in the space of a BBS note is, well, severely constrained to the point of marginal intelligibility.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
)