|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Kerning enabled by default | ||
|---|---|---|---|
| Product: | Writer | Reporter: | jvromans <jvromans> |
| Component: | code | Assignee: | michael.ruess |
| Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> |
| Severity: | Trivial | ||
| Priority: | P3 | CC: | issues, jigal, kendy, Mathias_Bauer, pavel, ralph |
| Version: | OOo 1.1 RC | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| URL: | http://specs.openoffice.org/appwide/text/MicroTypography.odt | ||
| Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
|
Description
jvromans
2003-07-15 10:53:01 UTC
Reassigned to BH I will second that. I've seen lots of people argue for turning some default-on items to off with replies that having them on is something that helps novices get used to the features. Why would not the same argument apply here. *** This issue has been confirmed by popular vote. *** So is this going to make it in the OOo 1.1.1 Version? If so lets get the Taget Milestone set. Yes, changing the default for switching on the kerning makes sense (pair kerning = on). But not in the options (means for each document), because still existing documents would be changed (e.g. visible as wrapped text), but within the document. With 1.1.1 underway, what is the status? I would provide options for a document-by-document setting as well as a global setting for kerning. In my case, I would have it on for all documents. Looking forward to this becoming a global option - why isn't it already? Thanks for great software! Hello Matthias, this issue is one for you. It treats a default change. And that theme is yours. Please consider this one for the rework of defaults. Thank you. Options for on/off and global/per document would be best. I would like to see the default set to 'on, global'. Users should have to go to one place only to change the setting. Could someone explain to me why the target for this is 2.0? How difficult is it to enable kerning by default? according to http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7690 this issue will be set to OOoLater FT: Even that this feature has a lot of votes pro kerning on there are still some arguments against it: 1. It is an un-written rule that we try _not_ to alter any long-standing defaults from version to version. 2. Our main competitor also uses the default OFF for this feature 3. Everyone who wishes to enabled kerning can easily do so by simply changing all default styles to kerning on. 4. A general setting for kerning does not make sense since it would alter the layout of alrtready existing documents. Give the con arguments this issue cannot completely recsolved in the 2.0 timeline and therefore must stay re-targeted to OfficeLater. > some arguments against it: > 1. It is an un-written rule that we try _not_ > to alter any long-standing defaults from version > to version. A) how can one know about an unwritten rule? How about this: This issue should have been fixed long ago, since it is an unwritten rule (I make it up just now) that issues are to be solved within two weeks. B) Postponing issues will automatically give them a long standing status. Argument invalid IMHO. > 2. Our main competitor also uses the default > OFF for this feature A) Everthing a competitor does is not "good" by default! B) The "main competitor" has many flaws and bugs in his programs. Even though users complain about this, these issues are never visible to the public. So we will never know how big an issue it is for their customers. Argument invalid IMHO. > 3. Everyone who wishes to enabled kerning can easily > do so by simply changing all default styles to > kerning on. A) This is way too much trouble for a feature that should have been turned on by default. B) Many users don't know what the word 'kerning' means. I've explained it to many and all agree that they've noticed it in texts and all agree that it looks better with kerning. Argument invalid IMHO. > 4. A general setting for kerning does not make sense > since it would alter the layout of alrtready existing > documents. I believe that existing OOo documents contain existing styles with kerning turned off. Other existing document will be converted anyway and thus the lay- out will most likely change. Argument invalid IMHO. > Give the con arguments this issue cannot > completely recsolved in the 2.0 timeline and > therefore must stay re-targeted to OfficeLater. This issue is more than one year old!!! Postponing action until the UI Freeze for 2.0 is a fact is not the correct way to handle this IMHO. It can't be too much trouble to turn on kerning by default in all styles for new documents in 2.0. No UI change needed. Even though many users will not know what the term "kerning" means they will notice that a document looks better. It would be a good idea in general to someone who knows about typography design the default styles. I used to recognize WordPerfect and Word documents by their default styles, which are by the way not typographical gems. Having a good default lay-out can make the user prefer OOo over a competitor, simply because their first document already looks better than anything they've made before! It could be good argument also for marketing: *We* have it turned on by default! >> 4. A general setting for kerning does not make sense
>> since it would alter the layout of alrtready existing
>> documents.
> I believe that existing OOo documents contain existing styles with kerning
> turned off. Other existing document will be converted anyway and thus the lay-
> out will most likely change.
Moreover, 2.0 will have completely new document formats replacing the
traditional .sxw formats. The default can thus be coupled to the new format,
with 100% guarantee that no existing documents will be harmed.
I agree. The new 2.0 release is the *perfect* moment to add kerning. This isn't just a major release. We are switching to a different file format. There are no legacy files, and people won't be surprised that a different format looks slightly differet (better). I also agree that this is a good marketing opportunity. Now, since the arguments for and against come down to marketing, why don't we let marketing decide? Does that sound like a reasonable, unbiased alternative? We do have a marketing group. Let's bring the issue up to them. Please subscribe to dev@marketing.openoffice.org Later today I will post this question to the marketing group. Cheers, Daniel. > 2. Our main competitor also uses the default OFF for this feature The main competitor is not the arbiter of what is good and bad. > 3. Everyone who wishes to enabled kerning can easily do so > by simply changing all default styles to kerning on. Most users don't know what kerning is and won't set it, give people what is good for them. > 4. A general setting for kerning does not make sense since it > would alter the layout of alrtready existing documents. Surely not so because the kerning value should stored in the existing documents(?). Also note other changes have upset the layout, "use printer fonts" in particlar completely corrupts layout. from what i have read it seems that actually there are no more arguments against kerning set by default. i could bet that more than 90% of oo.org users have no idea what kerning is - so current situation requires them to find out what the hell that is, why would they want it and then enable it. enabling kerning would affect only new documents - all old ones would remain the way they were created, so no layout changes would be neccessary. some possible arguments against kerning : a) there are fonts with broken kerning information. so what ? there are broken ttf fonts, no doubt - should we stop supporting ttf at all ? besides, how many such fonts are there ? b) kerning code in oo.org is faulty. if so, we should concentrate on fixing it, finding problems etc, so that kerning can be safely enabled by default. i believe though it isn't so - i haven't seen any problems lately with kerning. so, kerning should be safe by default - my suggestion is - enable it for 1.1.3. most people will not even notice it, some will notice that heir documents (created with 1.1.3 or later) are better looking. i can see no harm in such a decision. if there are any, could we discuss them as fast as possible, so that this issue is not dragged into next year and further ? So who actually makes the decision on when this whould be implamented? Maybe we are all just barking up the wrong tree. At any rate I don't see any results. hmm.. over a year later and no progress at all for such a tiny option.. I guess we were barking up a tree in a very remote spot of the forest since progress is non-existing. With 2.0RC coming up, what is the status??? well, this issue also has relatively few votes. maybe some rallying in mailing lists would help ? :) @richlv: You mean that voting actually influences the way issues are handled? ;-P This is such a little thing to fix; no GUI to change, no programming to do, only adding a single attribute to the default template... There is more time spend here discussing the whole issue then it would take to implement. And even with so few votes, almost 2.5 years is a bit long to leave it open IMHO. well, if we could get excessive voting going on, somebody might notice, i hope :) from this thread it seems that there are no real objections - this issue has just disappeared from radar. anybody feeling brave enough to write some provocative mail on, for example, discuss list ? :) This is really sad. I was just browsing through the oooforum.org and found that there are TONS of feature requests like this which have not got into OOo2.0, and which are really not from Mars which means they are not too complicated. Seriously, i don't believe they will ever get in OOo3 because even if some people remember them, they will be forgotten another time, like it seems to be the case with this one. I am just writing my diploma with OOo, some collegues use Word, some LateX. I must confess that i have the suite with the least features. There are good (really thick) books on how to make it with Word, and the LateX folks also have a solution for everything. ...ok, this is not related to this issue, its just a global remark. Any chance to get this fixed? For me, it doesn't seem to be a huge challenge. Too many votes -> change target. Indeed, the fix seems to be quite trivial. Re-filed from issue 35873: --- svx/inc/akrnitem.hxx 2004-10-15 19:24:32.399851088 +0200 +++ svx/inc/akrnitem.hxx 2004-10-15 19:24:58.966812296 +0200 @@ -93,7 +93,7 @@ class SvxAutoKernItem : public SfxBoolIt public: TYPEINFO(); - SvxAutoKernItem( const BOOL bAutoKern = FALSE, + SvxAutoKernItem( const BOOL bAutoKern = TRUE, const USHORT nId = ITEMID_AUTOKERN ); // "pure virtual Methoden" vom SfxPoolItem So, it is not ENHANCEMENT, but a PATCH... *** Issue 35873 has been marked as a duplicate of this issue. *** mmp: isn't 2.1 good target for this issue? yes, 32 votes and a patch are good reasons to consider this for OOo 2.1. I will have a look into it.Stay tuned and don't forget to nudge me if nothing has happend unti end of September. UI Freeze for 2.1 is mid of October. cheers /Matthias mmp: agreed. So setting the target to 2.1 as it is much easier to track then. Why do you thing this affect UI? Specification is published at: http://specs.openoffice.org/appwide/text/MicroTypography.odt go for implementation. Oliver, do you take care for all affected OOo modules? feature freeze for this issue is Oct-15 I am sorry - I have to retarget this to OOo 2.2. Feature freeze for 2.1 is tomorrow and Oliver is on an external training this week. I am truly and deeply disappointed. For a one-bit change that has been discussed (and postponed for years and finally got approved months ago, this is a very stupid reason for yet another delay. It's not quite as simple as the suggested change to SvxAutoKernItem. That change would break the rendering of existing documents, as well as the consistency between formatted and unformatted cells in Calc. Issue 35873 had already been changed from "Patch" to "Enhancement". SBA->NN: Thank you for the intro. Some further explannations: I change this issue from "Patch" to "Enhancement" as well. Background: This is not a bug fix, it is a general change in behavior that needs a finalised specification. The specification itself is not in Status "final" yet. This is not pea-counting of an obsessed tester. No way! It is _NEVER_ a matter of the amount of changed bits in the code. This kerning change affects EVERY USER, ALL THE TIME when he/she uses the office and looks at a document with text. I do this (QA) for a wghile now and we have experienced so-called "show stopper issues" in the midst of every milestone in the past years. And YES, SOME of them were based on code that came in "through the back door" without anybody taking notice of the danger that a "small, efficient, cool" change means once you dig deeper into it or have the one devastating scenario you did not think of when testing the functionality. Regressions are a common thing and they must be found BEFORE a small, cool change makes it into the code line. Therefore we have set up several rules how the chaos of "everybody believing this is a must-get-in-NOW" can be tamed. I am are well aware that there are people out there who see all QA as a hinderance of a free and creative programmer. On the other hand, to compose a software of this complexity without tight rules will cause "many tears". The implementation is done. ->mmp: What about the spec? . spec is done, target is OOo 2.2 Taking over for QA'ing. Setting to "fixed". Verified in CWS autokerning. Closed, checked in OOF680m2. |