Created attachment 466 [details]
Word file with Small Caps

The price of MS Office and OO isn't the same either. ;-)
Michael: Is it different opinions of "What looks good" or a bug?
Reasigned.

Actually I did a bit of a search on what "small caps" should be and
there doesn't seem to be a strict definition but font designers appear
to have a rule of thumb that the small caps height should be about the
same size as the "x-height" of the font, the x height the height of
lowercase letters minus their ascender (bit sticking up), i.e. the
height of an x.
(http://ourworld.compuserve.com/homepages/profirst/x.htm#x-height)

So considering the height of an x vs the small caps size, I see that a
ms small caps letter is slightly bigger than a lowercase x in the same
font, and a writer one is slightly smaller than the x. Some
definitions of "small caps" come down right in favour of this approach
of small caps being the same size as the x-height or a little larger,
(e.g. http://ourworld.compuserve.com/homepages/profirst/s.htm#smca). 

Some definitions are different, but there is an argument for having
small caps as big as, or bigger, than the lowercase of the same font.

Writer has about 80% (it is hard coded!) of the whole character height
for small caps. There does not exist a fixed definition how big small
caps have to be.
I compared Word and Writer each with the mentioned rule of thumb and
Writer (though it is a bit below this rule) comes much nearer to that
rule than Word does.
If someone wants the hard coded value change to a variable calculated
value depending on the height of the "x" of the corresponding font, an
"enhancement" has to be requested to the product management.
Myself, i do not see any reason, why OpenOffice should  adapt to MS's
conception of this. They do not really set EVERY standard.

I reopen it and send it back to jmills.

MRU->JMILLS: I give it back to you for this case you want to create an
enhancement of it to the productmanagement.

*** Issue 4960 has been marked as a duplicate of this issue. ***

For the record, if we implement a compatability option for this, then
there is an additional compatability option in word itself, for
"larger small caps like word 5.x for macintosh" which shouldn't be
forgotten.

Jonathan, if you want somebody to take care of the issue, please
change the "issue type" to "feature", cause all given explanations
tell me that we're definitely not talking about a bug here. The please
re-assign the issue to Bettina (bh@openoffice.org). I change the
target to "OOo 2.0", cause I don't want to have untargeted issues.

A compatibility mode would be a good idea, but as it's over 2 years
from the document I had the problem with, I'll close this until
someone else opens it or I get another instance of i.

I find the Small Caps size issue to be a problem worth solving from 2 aspects:

1. _Compatibility_: I had a title in small caps, but when the file was opened in
MS Word, the sentence was too long to fit in one line, which destroyed my whole
page layout. From this aspect, we are talking about a bug. 

2. _Professional design_: since Writer already has many professional design
features, this one would is quite obviously lacking - the user should be able to
decide the percentage of the Small caps size (like in Pagemaker). I would assume
this is not to hard to implement. Among other choices you could also offer MS
Word percentage, for compatibility. From this aspect, we are talking about an
enhancement.

as there seems to be additional support from other people please can we make
this and enhancement request...

so i reopen it to make it an enhancement request

Reassigned to bh.

Because of limited resources for OOo2.0, I have to re-target this task to 'OOo
later'.

This is an important issue, at least from a typographical point of view. Using a
fixed ratio for smallcaps is a problem because of the varying ratio between
x-height and font size. MSOffice's choice of 80%, while in many cases being too
big, at least ensures that the smallcaps will be equal to or bigger than the
lowercase letters in 99% of the cases, whereas OOo Writer's choice of 67% will
give good results on the classic renaissance fonts with a small x-height, but
for most modern fonts with a larger x-height, the small caps will be smaller
than lowercase letters, which is BAD, whichever way you look at it.
So: either an option to scale the smallcaps size manually (for each document,
for each character/page style, or as a default for the application), or a larger
pre-set ratio, would be nice. 
This should not be done for compatibility reasons, since MS Word also has a
"bad" solution - it's not their solution that we want to emulate here, but we
want to avoid the pitfalls of the OOo solution (i.e. smallcaps too small
relative to lowercase, for 80% of all fonts)(or thereabouts)

Wouldn't there be a way to include a typographically more or less correct size
of small caps depending on font properties (x height)?

The - apparently quite good - German Wikipedia article on "Kapitälchen" names
two major problems for fake small caps (in contrast to genuine small caps that
are included in fonts): They are either too tall (Word) or too lightweight (if
reduced to x height). In either case they catch ones eye if one looks at a text
from a certain distance. Wouldn't it be possible to chose the x height and print
them somewhat darker than letters just reduced in size? Furthermore small caps
should be spaced by .5 to 1 point according to the article. (Any comments of
typography specialists?)

If an automatic solution is not feasible, I'd plead for a manual percentage
setting, too.

To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements". 

The result of the too small resizing factor is absolute inappropriate also for 
the "poor man's DTP" with fake small caps of word processors. Mixed letters 
(letters with different weights), and lower small caps, than lower letters of 
most of the title fonts are the worst and most perceptible typographic errors.

This is one of the most serious OpenOffice.org migration problem for a Hungarian 
governmental body, so I have attached a patch and an explanation. The PDF is 
generated by the patched OpenOffice.org from the test file. Based on the basic 
elements of typography, the bad fake small caps resizing factor is a bug of 
OpenOffice.org, resulting real migration issues.

Created attachment 72033 [details]
Fix fake small caps resizing factor

mba: this is not a requirement, but a bug in word processing, see my previous 
comment and the attached PDF.

Created attachment 72034 [details]
Typographic explanation of the fake small caps problem of OOo

Created attachment 72035 [details]
Source document of the generated PDF

The attached source document is the test file of the patch.

Fixed in LibreOffice. Now LibreOffice has two acceptable standard letter variants 
for the inner-text highlighting: cursive and small caps (inner-text bold is often 
not an option because of its different brightness), see the attached explanation.

Oliver, please take over

I agree the lack of consistency between MS-Word and OpenOffice is a huge problem, and this report has been waiting for too long to get fixed!

Unfortunately the link to the compuserve links are dead now so I don't have a rule of thumb to set the default size accordingly. It does seem like MS-Word seems to go above what would've been ideal, so I tend to be conservative here.

Changing the values from 66 to 80, as the patch suggested is a bit drastic, so somewhat arbitrarily I set the default values to 75 for the time being.

Committed as revision 1180758.

Of course, this can be reviewed again with proper argumentation.

For the consistency between OpenOffice.org and LibreOffice, Novell has added a condition to the false small caps size, so only new documents use the new values (80%). Please, consider to check LibreOffice's method before using a third value.

Whichever value one chooses on this case is likely to cause controversy but I still think it was good to take action now, with the excuse of the new release under Apache, than to keep waiting for a perfect solution.

The "compatibility" option has not been shared with us, so I don't think it was meant to keep compatibility with modern OOo :(.

The compatibility mode is not without problems: it adds complexity but perhaps most disturbing is that the editor won't be consistent within itself. Think of copy-pasting from an old document to a new one, without any configurable option to set both equal, or the many devices that have broken/unset clocks.

I prefer a consistent value for all cases.

Conversion problems are likely to happen always. I ultimately set the value to 74, under the (admittedly arbitrary) argument that while rounding to the nearest tenth it's the highest I can go without really changing the value.

A question here would be .. why 80%? Would that save the conversion issues with MS-Word? (From the first comment 85% would be required for that).

Reset assigne to the default "issues@openoffice.apache.org".