bugFree UCS Outline Fonts - Bugs: bug #56759, Small Caps look like Petite Caps

 
 

bug #56759: Small Caps look like Petite Caps

Submitter:  Sergio Callegari <callegar>
Submitted:  Wed 14 Aug 2019 04:10:42 PM UTC
   
 
Category:  overall font problem Severity:  3 - Normal
Item Group:  bulk text appearance poor Status:  Postponed
Privacy:  Public Assigned to:  Stevan_White
Open/Closed:  Open Release:  * 2012-05-03
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 15 Aug 2019 05:09:22 PM UTC, comment #2: 

Thanks for the extended and information rich answer!

> in the latest version control, small caps are greatly expanded relative to the 2012 release


Is there any "built" version of the fonts that is recent enough to try?

> the URW fonts on which the Latin faces are based were meant to resemble the Adobe Times-Helvetica-Courier set, not on the Microsoft faces


Obviously... My mistake: I wrote MS in place of Adobe in my report...

> I also found this discussion:

https://graphicdesign.stackexchange.com/questions/125452/how-and-when-should-petite-caps-be-used

While I am not by any means an expert, I have always got the feeling that the matter is about the fact that there are different uses for small caps which may involve having them either in running text together with small letters or in isolated environments with no close by small letters (e.g., headings). For the first case, it is nice to have the small caps as tall as the small text because they mix more harmonically in this way. However, for the second case, the visual effect is generally more pleasing if the small caps are taller, at least for fonts with a little x-height, because the intention is more similar to that of giving emphasis in an all-caps like way (think of ringing with capitalis monumentalis, inscriptional capitals, elegant capitals), while still wanting to maintain non-capitals recognizable from the real capitals. Distinguishing small and petite caps satisfy both these needs.

Apart from any theoretical discussion, which is quite interesting, there is a real practical problem, though. This is when you need to adhere to some institutional, departmental or editorial style guide which prescribes typesetting rules based on  the appearance of some commercial font (typically Adobe or Monotype Times or Times New Roman). E.g., if you are invited to do headings in Adobe Times Small Caps, you cannot really use something visually diverging from it.


Sergio Callegari <callegar>
Wed 14 Aug 2019 05:43:06 PM UTC, comment #1: 

Hi Sergio!

You have a point, and it is well taken.  However, I have no intention of producing an intermediate-sized set of letters.  This would be a far greater chore than you might imagine, and there's already too much to do in this project.  Really, I just can't.  But it's also not so clear-cut as you might imagine.  For one thing, in the latest version control, small caps are greatly expanded relative to the 2012 release.

As to the choice of height of small caps:  yes, it was a design choice, and a deliberate one.  We did not intend to implement a petite caps, but there was a need for some kind of small caps, and a need for them to harmonize with lowercase letters.  It isn't at all clear, for example, how "small caps" Unicode character should correspond to typographical smal caps and petite caps, if those are to be distinct.

Regardless of what happens in GNU FreeFont itself, you are of course free to make your own font, based on FreeFont, alter it at will, and distribute it accourding to the GPL.  We also ask that you give the fonts a different name.  It would be nice if you could mention where you got the original sources.

GNU FreeFont has never been based on the Micorsoft fonts, nor meant as a "drop-in replacement" for them.  The project was started in order to fill a gap left by the withdrawal of the freely-available Monotype fonts.  But the URW fonts on which the Latin faces are based were meant to resemble the Adobe Times-Helvetica-Courier set, not on the Microsoft faces.

We do not follow the Microsoft font styles, or the style of any other existing font, in any way.  We take pains to do things our own way and maintain a degree of stylistic independence.

As to just what "petite caps" ought to be: 

I'm not convinced this was written in stone, and the idea that the distinction should be as you describe is a fairly recent development.  As I recall, just a few years ago, petite fonts were only said to be smaller than small caps. The Wikipedia page now reflects what you have said, but that has been written recently.

Hugh Williamson's Methods of Book Design (1956)  states:

"Nearly all roman founts for text composition include small capitals, which are similar in x-height to the lower-case letters. Being intended for occasional use with the lower-case letters, they are usually designed with strokes of similar thickness, and therefore tend to be rather heavier in proportion to their height than ordinary capitals ; in order to maintain the size of their counters, they are often drawn rather wider in proportion too."

He doesn't mention anything about petite caps, but describes different approaches to small caps.

I also found this discussion:
https://graphicdesign.stackexchange.com/questions/125452/how-and-when-should-petite-caps-be-used

I would really like to see this article, which was mentioned in the Wikipedia article on "small caps"
Smith, Margaret M. "The Pre-history of 'Small caps': from all caps to smaller capitals to small caps". Journal of the Printing Historical Society. 22 (79–106).

Thanks for your observations and recommendations!


Steve White <Stevan_White>
Group administrator
Wed 14 Aug 2019 04:10:42 PM UTC, original submission:  

The Small Caps provided in GNU Free Serif have a visual aspect that is very different from that of commercial Times Roman or Times New Roman counterparts.

To the best of my understanding one of the values of Free Serif is to be an almost seamless replacement of commercial Times Roman offers. The rooting of GNU Free Serif in URW++ Nimbus Roman that is metrically compatible with Times Roman seems to support this point. If this is the case, divergence on Small Caps is an issue as it may hinder usage of Free Serif in place of commercial fonts when Small Caps are required and visual consistency is a must.

The issue is that GNU Free Serif has Small Caps letter with a very reduced height. In fact they are as tall as a small case "x". While this is a common choice, in fonts with relatively low x-height (such as Times Roman), small caps are generally somewhat larger than this. As a matter of fact, in Adobe/Microsoft/Monotype/Linotype offers the Small Caps height is larger than the x-height (probably 20-30% larger, about 70% the height of full capitals). For these cases, the x-height form is generally called Petite Caps preserving the Small Caps for the larger variant.

Note that the same issue is also present in TeX Gyre Termes and other free fonts. This basically leaves users without a Times Roman metrically compatible free font with visually compatible Small Caps:

- STIX Two is Times lookalike with proper height Small Caps, but is not metrically compatible with Times Roman (particularly in the bold variants);

- STIX is obsolete and does not have Small Caps;

- XITS does not have Small Caps;

- TeX Gyre Termes has too small Small Caps (in fact Petite Caps);

- Tinos does not have Small Caps;

- Thorndale does not have Small Caps;

- Tinos dows not have Small Caps;

- Linux Libertine and variants have too small Small Caps (again in fact Petite Caps).

Would be great if GNU Free Serif could move its current Small Caps offer under Petite Caps and provide Small Caps with a similar height as that in commercial counterparts.

Sergio Callegari <callegar>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by Stevan_White (Posted a comment)
  • -email is unavailable- added by callegar (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-08-14 Stevan_White StatusNone Postponed
        Assigned toNone Stevan_White

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code