Issue 1526 - Small Caps are different sizes twixt Word and StarWriter
Summary: Small Caps are different sizes twixt Word and StarWriter
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: 633
Hardware: PC Windows ME
: P3 Trivial with 3 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 4960 (view as issue list)
Depends on:
Reported: 2001-08-24 16:28 UTC by jmills
Modified: 2017-05-20 11:22 UTC (History)
7 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

Word file with Small Caps (19.00 KB, application/octet-stream)
2001-08-24 16:28 UTC, jmills
no flags Details
Fix fake small caps resizing factor (2.03 KB, patch)
2010-10-13 09:33 UTC, nemeth.lacko
no flags Details | Diff
Typographic explanation of the fake small caps problem of OOo (102.17 KB, application/pdf)
2010-10-13 09:42 UTC, nemeth.lacko
no flags Details
Source document of the generated PDF (14.64 KB, application/vnd.oasis.opendocument.text)
2010-10-13 09:44 UTC, nemeth.lacko
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jmills 2001-08-24 16:28:16 UTC
The Small CAPS in fonts between Upper Case and Lower case
are diffrerent between Word and Writer. See attached file
(Print one from WOrd, One from StarWriter and position one over the
other infront of a lamp.  You can see the MSFT small caps are
larger than OOo's.

It seems that Star is using a factor of about 67% of the BIG cap size
whereas MSFT seem to be using about 85%.

attachment to follow....
Comment 1 jmills 2001-08-24 16:28:56 UTC
Created attachment 466 [details]
Word file with Small Caps
Comment 2 stefan.baltzer 2001-08-28 17:00:28 UTC
The price of MS Office and OO isn't the same either. ;-)
Michael: Is it different opinions of "What looks good" or a bug?
Comment 3 caolanm 2001-08-28 17:24:39 UTC
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.

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,

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.
Comment 4 michael.ruess 2001-08-30 14:53:35 UTC
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.
Comment 5 michael.ruess 2001-08-30 14:55:47 UTC
I reopen it and send it back to jmills.
Comment 6 michael.ruess 2001-08-30 14:57:17 UTC
MRU->JMILLS: I give it back to you for this case you want to create an
enhancement of it to the productmanagement.
Comment 7 caolanm 2002-05-17 09:15:27 UTC
*** Issue 4960 has been marked as a duplicate of this issue. ***
Comment 8 caolanm 2002-11-01 16:00:48 UTC
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
Comment 9 michael.bemmer 2003-03-31 08:13:41 UTC
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 ( I change the
target to "OOo 2.0", cause I don't want to have untargeted issues.
Comment 10 jmills 2003-09-29 13:31:16 UTC
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.
Comment 11 matjazcrnivec 2004-10-15 12:23:00 UTC
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
Comment 12 jmills 2004-10-19 16:03:56 UTC
as there seems to be additional support from other people please can we make
this and enhancement request...
Comment 13 jmills 2004-10-19 16:04:59 UTC
so i reopen it to make it an enhancement request
Comment 14 bettina.haberer 2004-10-20 09:49:24 UTC
Reassigned to bh.
Comment 15 thorsten.ziehm 2004-11-23 09:53:37 UTC
Because of limited resources for OOo2.0, I have to re-target this task to 'OOo
Comment 16 eyolf 2005-09-21 13:19:32 UTC
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)
Comment 17 rollom 2006-04-25 15:53:13 UTC
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.
Comment 18 bettina.haberer 2010-05-21 14:48:54 UTC
To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements". 
Comment 19 nemeth.lacko 2010-10-13 09:28:38 UTC
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 migration problem for a Hungarian 
governmental body, so I have attached a patch and an explanation. The PDF is 
generated by the patched from the test file. Based on the basic 
elements of typography, the bad fake small caps resizing factor is a bug of, resulting real migration issues.
Comment 20 nemeth.lacko 2010-10-13 09:33:44 UTC
Created attachment 72033 [details]
Fix fake small caps resizing factor
Comment 21 nemeth.lacko 2010-10-13 09:40:04 UTC
mba: this is not a requirement, but a bug in word processing, see my previous 
comment and the attached PDF.
Comment 22 nemeth.lacko 2010-10-13 09:42:32 UTC
Created attachment 72034 [details]
Typographic explanation of the fake small caps problem of OOo
Comment 23 nemeth.lacko 2010-10-13 09:44:31 UTC
Created attachment 72035 [details]
Source document of the generated PDF
Comment 24 nemeth.lacko 2010-10-13 09:45:20 UTC
The attached source document is the test file of the patch.
Comment 25 nemeth.lacko 2010-12-14 09:34:36 UTC
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.
Comment 26 Mathias_Bauer 2011-01-03 18:18:49 UTC
Oliver, please take over
Comment 27 Pedro Giffuni 2011-10-10 02:06:04 UTC
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.
Comment 28 nemeth.lacko 2011-10-10 08:51:51 UTC
For the consistency between 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.
Comment 29 Pedro Giffuni 2011-10-10 14:46:25 UTC
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).
Comment 30 Marcus 2017-05-20 11:22:37 UTC
Reset assigne to the default "".