Posted: Mon Jan 24, 2005 7:52 am Post subject: Rant: Why no attempt to fix the font menu on NeoOffice?
The #1 thing that makes NeoOffice/J look like a second-class citizen on OS X is that the font menu lists italic and bold variants of a font as separate fonts, and what's worse is that there seems to be no plan to fix this:
Quote:
Neo/J, however, uses the OOo code which only supports a single list of fonts. Trying to make OOo emulate the native Mac OS X style is way outside the scope of Neo/J as so I am closing this bug as "won't fix".
Never mind that this has nothing to do with "emulat[ing] the native Mac OS X style." Last time I checked, the only platform on which OOo/NeoOffice lists italic and bold variants as separate fonts is Mac OS X.
Posted: Mon Jan 24, 2005 9:59 am Post subject: Re: Rant: Why no attempt to fix the font menu on NeoOffice?
jjramsey wrote:
Never mind that this has nothing to do with "emulat[ing] the native Mac OS X style." Last time I checked, the only platform on which OOo/NeoOffice lists italic and bold variants as separate fonts is Mac OS X.
Your statement is flat-out false. My wife just opened StarOffice 7 (which uses the OOo 1.1.x code) on Solaris and all of the fonts that have bold and italic variants have separate entries in the font list.
Posted: Mon Jan 24, 2005 1:10 pm Post subject: Re: Rant: Why no attempt to fix the font menu on NeoOffice?
pluby wrote:
jjramsey wrote:
Never mind that this has nothing to do with "emulat[ing] the native Mac OS X style." Last time I checked, the only platform on which OOo/NeoOffice lists italic and bold variants as separate fonts is Mac OS X.
Your statement is flat-out false. My wife just opened StarOffice 7 (which uses the OOo 1.1.x code) on Solaris and all of the fonts that have bold and italic variants have separate entries in the font list.
On Fedora at least, the fonts are not separated out into bold and italic versions. IIRC, that's true of Windows as well. For Fedora, at least, it may be a fontconfig thing. That said, I've never seen StarOffice or OpenOffice separate out the bold and italic variants. Then, the latest version of StarOffice I've used has been a beta of version 6, on Windows. The separating out of bold and italic versions looks like some quirk that hits some platforms and not others, and it doesn't look intentional.
Does your wife's Solaris installation use XFree or X.org, or does it use Sun's own X implementation?
Whether you see a single font or separate variants depends on the combination of the windowing APIs and the font itself. In most X11 servers that I have used, the X11 server will show a single font for each font file. This is why on Solaris and OOo X11 on Mac OS X shows each SunSerif variant (a font shipped with StarOffice) as a separate font but they don't separate out the variants in the BitStream Vera Sans fonts.
Mac OS X's ATS font APIs return each variant as a separate font regardless of how they are stored in a font file and what you see in Neo/J is the list of native fonts (and their full name) that Java has loaded.
So why don't I just put in a bunch of code that chops off the variant names and combines them into a single font for the list? Because this would require a whole bunch of custom code to bridge OOo's font matching/bolding/italicizing code.
Sure this is feasible. Anything is feasible with time and money. However, the fact is that I already spend every minute of my free time working on this project fixing more mundane crashing and other stability bugs. Accordingly, I limit my work to a scope that I can reasonably accomplish in my available time which means that "polish" issues take a back seat to "stability" issues.
I already spend every minute of my free time working on this project fixing more mundane crashing and other stability bugs. Accordingly, I limit my work to a scope that I can reasonably accomplish in my available time which means that "polish" issues take a back seat to "stability" issues.
Fair enough as far as it goes, but that only justifies putting the bug on the backburner, not for marking it "wont fix," which just shuts the door on it being fixed at all.
I can see why Sun wouldn't bother fixing the problem in StarOffice. Sun seems to be transitioning to using Xorg in its newest and shiniest stuff, so it may be hoping that StarOffice will eventually use fontconfig on Solaris and make the problem moot. That's not applicable to Mac OS X, however.
IMHO, better to leave the bug open but at a low priority than to all but say "it's a feature not a bug" and mark it as "wont fix."
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Jan 27, 2005 10:52 pm Post subject:
<commence feeding>
I too mark many things as "Won't fix" for a number of reasons (nad ues, the bugzilla doesn't have a "feature/by design, not a bug" style reason for closing things. The "Won't fix" status is good in a way, though...
Right now NeoJ has a very limited mission. It is to get OpenOffice.org running natively on OS X. This means that everything OOo comes along, the good and the bad. Our goal isn't to make OOo more "Mac-like", only to get it to run.
For what it's worth, just getting it to run has taken over two years of Patrick's life. The fact that we have a font menu at all that's displaying the fonts with the right metrics has happened only through years of painstaking effort, tweaking, and bug fixing in font display. We still have problems with this, too, and those problems with our existing implementation are what we address in our bugzilla.
Right now our goal is just to get it to run correctly, OOo faults and all. If we can do that, then perhaps we can begin addressing the "Mac-like" issues. Until then, though, our goal is just to try and tackle the first major effort, so in our current mode we're definitely not going to fix these kinds of issues, so in a way "won't fix" is really applicable.
Honestly, I'd love to make NeoJ more "Mac-like", but it's too large of an engineering task to handle right now, especially without a full-time staff of at least 10 engineers. I tried doing it with Neo/C and, as a result, it became too unmanageable and thus just fizzled out and died. Focusing on getting NeoJ to run correctly is essential, not only from a foundational engineering perspective but also from the point of view of setting realistic goals that a volunteer staffed open source project can achieve with an 8 million line plus source base.
Right now our goal is just to get it to run correctly, OOo faults and all. If we can do that, then perhaps we can begin addressing the "Mac-like" issues. Until then, though, our goal is just to try and tackle the first major effort, so in our current mode we're definitely not going to fix these kinds of issues, so in a way "won't fix" is really applicable.
But one would hope at least that you won't be in your "current mode" forever. There's a difference between low priority and "won't fix," and Bugzilla already has the means to keep track of which is which. It even has a "deferred" status, which seems to be more appropriate. "Won't fix" implies that you don't think a bug should be fixed ever, even if you have the manpower to fix it. "Won't fix" makes sense for bugs in a soon-to-be obsolete version of a software (i.e. the GTK+ version of Amaya). It doesn't make sense for bugs that you might like to have fixed someday, eventually.
Quote:
Honestly, I'd love to make NeoJ more "Mac-like", but it's too large of an engineering task to handle right now [emphasis mine]
But there is a difference between "can't do it right now" and "won't do it ever." The latter is what "won't fix" communicates.
BTW, the reason that I'd consider having the bold and italic versions of a font available in the font list a Bad Thing™ is that it makes the interface for styling fonts bold and italic more confusing. Putting text in the "Times Bold" font isn't quite the same thing as putting text in the "Times" font and making it bold. Doing the former may lead the user to find that the "Bold" button on the toolbar won't toggle the boldness of the font. That makes it more than an aesthetic problem. Yes, compared to NeoOffice eating one's homework, it is definitely minor. It is a problem, though, and should be treated as a problem, even if the only treatment you can give for now is to put it on the backburner indefinitely. Better to leave a slim chance of it being fixed than none at all.
uh. no offense, but if that is your biggest complaint, then isn't that a good thing? i mean seriously, you are using a free program, ported by two people, and it is so stable, and functions so well that your complaint is the font menu.
however, let us not be unreasonable. i'm sure that we can come to a comprimise, ed and patrick simply figure out how long it would take to do, estimate about $100 an hour each for your time and name a price.
or. we could worry about things like 1.1.5 and 2.0...
Putting text in the "Times Bold" font isn't quite the same thing as putting text in the "Times" font and making it bold.
Exactly.
Which is why I prefer to see which fonts will give me a proper bold and italic and which will be beefed up or tilted by the application.
Maybe I've spent too long working with Quark-using typography freaks, but for me, this is feature not bug.
Except that this isn't a consistent feature across platforms, but a quirk based on what font list the platform makes available to NeoOffice. Patrick already pointed that out. Also the difference between putting text in the "Times Bold" font and putting text in the "Times" font and making it bold is that the former makes it seem that the button for toggling the boldness of the font "mysteriously" stops working.
jakeOSX wrote:
however, let us not be unreasonable. i'm sure that we can come to a comprimise, ed and patrick simply figure out how long it would take to do, estimate about $100 an hour each for your time and name a price
I already suggested a "compromise," which was to put the bug on the backburner indefinitely instead of closing off any future possibility of fixing the bug at all.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon Jan 31, 2005 11:12 pm Post subject:
<feeding>
Well, it's been marked as something that won't be fixed and given the current staff/goals/priority/etc. of the project the reality of the situation is it won't be fixed. Deferring it will just string you out with false hope; there's no sense in deferring something that just won't be worked on in the immediate future. It's not like it's erased from the database; it's not like someone can't go back and look at all of the bugs with that status in the future.
Unfortunately, ranting about a bug that's been marked as as "won't fix" won't actually do anything productive to get it fixed. Rather it may just annoy people enough that it actually won't get fixed
Like jake suggested, if there are issues like this that really really bug you please feel free to proactively find constructive ways to get it solved like helping to find more developers, raising some kind of a bounty for the feature, or going out and and finding an alternative solution that meets your needs. Believe it or not, MS Office is actually a really good application and well worth its price, too.
And on that note I'm going to move this thread to our new "Ranting" forum where we can continue to rant at each other all we like in a unique place that we can ignore should we need to gain back our productivity
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
