bugFree UCS Outline Fonts - Bugs: bug #39029, subs, sups, smcp and c2sc OT...

 
 

bug #39029: subs, sups, smcp and c2sc OT features

Submitter:  Emmanuel Vallois <emmanuel_vallois>
Submitted:  Tue 21 May 2013 12:21:55 AM UTC
   
 
Category:  individual character(s) Severity:  3 - Normal
Item Group:  character substitution issue Status:  Proceeding
Privacy:  Public Assigned to:  Stevan_White
Open/Closed:  Open Release:  * development
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 27 May 2013 12:19:05 PM UTC, comment #7: 

I posted changes that fix several of your new observations.

Let me say again, you're amazing -- not just the tests, but your ability to catch these little things -- some of them I don't see even when I flash between examples many times.

Bulgarian
---------
I'm not sure about the K.  This less of a question of form
and into a question of decoration...I was just experimenting
with implementing some examples I had before me.
To me, some of the other Bulgarian changes lend to readability.
I don't see how this one does..

Greek
-----
I like the idea of mapping small cap final sigma to s,
but I have no idea what the conventions might be.

Devanagari
----------
As I mentioned before, it's unclear how features such as 'hlig' should interact with Indic features, or whether they should be activated at all.  The documentation is very hazy on
this, with the result that it is implemented differently on
different platforms.

Steve White <Stevan_White>
Group administrator
Mon 27 May 2013 01:25:15 AM UTC, comment #6: 

I take note of steady progress towards fully working features, and I updated my files, including test for small-cap Cyrillic and Greek just added to FreeSerif.

About Bulgarian styles: I do not know which forms are correct in Bulgarian, the only thing I tried to point out was consistency: we should have the same in Regular and Bold. This is not the case today. So I see two possibilities:

  • there are too much substitutions done in Regular and some must be removed; or
  • there are some that got forgotten in Bold (and a few in Italic faces).

My remarks were based on the second interpretation.

I agree with you on CSS and small-caps. If some small-caps got encoded, it is because they may have different meaning in some phonetic notation. When letters are used to denote phonetics, it does not make sense to apply any of the subs, sups, smcp and c2sc features. These would be used when letters are used in an actual orthography; and for smcp and c2sc when that orthography is bicameral.

(file #28183, file #28184)

Emmanuel Vallois <emmanuel_vallois>
Sun 26 May 2013 09:44:53 PM UTC, comment #5: 

Just submitted changes regarding the'hlig' historical ligatures table for Old Hindi.

Two main issues: 1) unclear on when 'hlig' is executed with regard to other Indic tables.  Had it in front, now it's placed at end.  Does it make a difference? 2) Had hoped to execute before other transformations, so contents had raw viramas, etc.  But other transfromations were occurring before this table, making matches impossible.  So: inserted sequences to match the transformed strings.

This was always rather crude.  I'm not sure if it doesn't match too much...

To see what I'm driving for, see the big table of ligatures on p. 22 of the velthuis font manual,
http://www.tex.ac.uk/tex-archive/fonts/devanagari/velthuis/doc/generic/velthuis/manual.pdf
The 'hlig' lookup is meant to implement the column headed 'MH' in that table.

Steve White <Stevan_White>
Group administrator
Fri 24 May 2013 08:58:36 AM UTC, comment #4: 

Regarding the purpose of CSS: a policy is starting to gel.

The purpose of CSS ought to be for styling, and very decidedly, it is not to achieve a different Unicode code point.

For example, it is appropriate for CSS "small cap" to change a small latin m to its small capital style.  It is not appropriate for CSS to change the IPS turned r to the IPS turned capital R -- these symbols mean different things.

This gets tricky when the same Unicode point is used in a real language, as are many of the funny latin-based letters.  I'm not sure the rule can be consistently applied in Unicode--I think there are cases of IPA letters whose styled version means something different, but the letter has been adopted in some African language. But I think there the application of style to the real spoken language would trump the accidental inappropriate application to a symbol.
That is, it makes sense to go ahead and make a rule for the styled version of the letter.

Steve White <Stevan_White>
Group administrator
Tue 21 May 2013 10:32:46 PM UTC, comment #3: 

About the Bulgarian styles: I explained this before, I think the ones you mentioned are in fact right.  As with Cyrillic generally, the normal forms are often quite different from the italic.  The only one I corrected was the form of the 't' in bold.

Steve White <Stevan_White>
Group administrator
Tue 21 May 2013 09:01:11 PM UTC, comment #2: 

I just made a commit that addresses many of the issues shown in your examples.  I'm sure I missed a lot.

I disagree on a couple of points:

  • The schwa is used as a proper letter in several alphabets.

  See http://en.wikipedia.org/wiki/Latin-derived_alphabet.
  Part of the point of the small caps is non-Unicode, purely
  typographical.  It happens that the small schwa is the small
  caps form of small schwa.

  • I'm unconvinced about U+A7FA small capital turned m.

  I'm impressed that you noticed this.  I had too.  Hmmm.
  I need to see some other standard, where the funny form in the
  Unicode sample is explained.



Steve White <Stevan_White>
Group administrator
Tue 21 May 2013 12:30:21 PM UTC, comment #1: 

Thanks again!  I'm looking at these.

Steve White <Stevan_White>
Group administrator
Tue 21 May 2013 12:21:55 AM UTC, original submission:  

This bug is to follow up work done on implementing these features.

Joined is an updated version of my overall test page, and a reduced  version of the table which allows to visualize the variants for each character and so easily spot the missing/wrong ones (well, that’s harder sometimes because of font substitutions, beware of these!). In this reduced table I got rid of all characters that do not have encoded variants and are not already present in the lookup  tables.

Emmanuel Vallois <emmanuel_vallois>

 

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

Attach Files:
   
   
Comment:
   

 

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 emmanuel_vallois (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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-05-27 emmanuel_vallois Attached File- Added Features test.html, #28183
        Attached File- Added subs, sups, smcp and c2sc OT features test.html, #28184
    2013-05-21 Stevan_White Assigned toNone Stevan_White
    2013-05-21 Stevan_White Categoryoverall font problem individual character(s)
        StatusNone Proceeding
    2013-05-21 emmanuel_vallois Attached File- Added Features test.html, #28122
        Attached File- Added subs, sups, smcp and c2sc OT features test.html, #28123
        Attached File- Added optional_features_test.py, #28124

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code