silgraphite-fonts

[Silgraphite-fonts] Double positioning & substitutioning rule

[Krzysztof S. <fla...@gm...>]

Hello.
I have another problem.

There is a rule in this steno-writing that makes letters crossed when they
are Consonant and Vowel, and there is R in between:
Eg. (crossing shown as "+")
*CrV = C+V*
ekran = ek+an
prototyp = p+ototyp
etc.
*VrC = V+C*
orka = o+ka
zerka = ze+ka
etc.
It is easy to make a rule for C+V, as in Polish there are only 6 vowels
that can be crossed, and there is anyway need to make separate glyphs for
them. But crossing V+C needs (as there is no need to make separate glyps)
to make double rule:

- substitution like clsVow clsR clsCons > clsVow clsCons:(2) _ ;
- positioning like clsVow clsCons {kern.x = -50m};

But such a kerning rule must not work, when just vowel and consonant meets,
it should work only when this pair is made by substitution in context of R.
I mean, to write something like "orkan", "arka", "zegarka" etc. I need to
remove R and move the consonant next to R back to make it crossed with
preceeding vowel.
In docs there is written, that firs all of substitutions are made, then the
results are send to positioning part. But this two changes excludes each
other: if I first remove R, then resulting pair would not be recognized as
R-pair.
Is it possible to work-around such conflict?

Thanks in advance for Your attention.
-- 
::| Nondum lingua suum, dextra peregit opus |::
fla...@gm...
* http://www.stenografia.pl *

Re: [Silgraphite-fonts] Double positioning & substitutioning rule

[Martin H. <mar...@si...>]

On Tue, 12 Nov 2013 14:52:30 +0100
Krzysztof Smirnow <fla...@gm...> wrote:

> Hello.
> I have another problem.
> 
> There is a rule in this steno-writing that makes letters crossed when they
> are Consonant and Vowel, and there is R in between:
> Eg. (crossing shown as "+")
> *CrV = C+V*
> ekran = ek+an
> prototyp = p+ototyp
> etc.
> *VrC = V+C*
> orka = o+ka
> zerka = ze+ka
> etc.
> It is easy to make a rule for C+V, as in Polish there are only 6 vowels
> that can be crossed, and there is anyway need to make separate glyphs for
> them. But crossing V+C needs (as there is no need to make separate glyps)
> to make double rule:
> 
> - substitution like clsVow clsR clsCons > clsVow clsCons:(2) _ ;
> - positioning like clsVow clsCons {kern.x = -50m};
> 
> But such a kerning rule must not work, when just vowel and consonant meets,
> it should work only when this pair is made by substitution in context of R.
> I mean, to write something like "orkan", "arka", "zegarka" etc. I need to
> remove R and move the consonant next to R back to make it crossed with
> preceeding vowel.
> In docs there is written, that firs all of substitutions are made, then the
> results are send to positioning part. But this two changes excludes each
> other: if I first remove R, then resulting pair would not be recognized as
> R-pair.
> Is it possible to work-around such conflict?

How about:

table(substitution)
pass(n)
clsVow clsR > @1:(1 2) {user1 = 1} _ / _ _ clsCons;
endpass
endtable

table(position)
pass(n)
clsCons {kern.x = -50m} / clsVow {user1 == 1} _
endpass
endtable

I.e. we set an attribute in the slot to indicate that the vowel is crossed and then we check that when we do the kerning.

HTH,
Yours,
Martin

Re: [Silgraphite-fonts] Double positioning & substitutioning rule

[Sharon C. <sha...@si...>]

Hello Krystof,

I'm not 100% sure I understand all the details of your problem, and 
there's something I'm not clear on. You say you are "crossing" the r 
with a vowel or consonant? Does the r actually get totally removed, or 
just moved somewhere? If it is still present nearby in some form, I 
would expect the positioning rule could include it somehow.

Anyway, supposing there is no way to access the r in the positioning 
rule, I can think of a few ways to handle this. (I see that Martin 
just responded with one of these suggestions, but I'll send anyway it 
since the email is already written!).

(1) Use a user-defined slot attribute to record the fact of the 
crossing, and test for it later.

#define rCross user1

table(sub)
clsVow  clsR  clsCons  >  clsVow  clsCons {rCross = 1};
endtable;

table(pos)
clsVow  clsCons_r {kern.x = -50m}  /  _  _ {rCross == 1};
endtable;


(2)  Define pseudo-glyphs that look like the original glyphs, but 
"know" that they need the R-positioning. This is much messier; the 
advantage is that you don't have to do the testing which *can* be 
slow. I doubt speed is a problem for your font, so I'm guessing option 
(1) above is better for you.

table(glyph)
gConsB_r = pseudo(unicode(0x0062));  // displays as the default glyph 
for "b"
gConsC_r = pseudo(unicode(0x0063));
gConsD_r = pseudo(unicode(0x0064));
...
clsCons_r = (gConsB_r, gConsC_r, gConsD_r, ...);
endtable;

table(sub)
clsVow  clsR  clsCons  >  clsVow  _  clsCons_r;
endtable;

table(pos)
clsVow  clsCons_r {kern.x = -50m};
endtable;


On 11/12/2013 7:52 AM, Krzysztof Smirnow wrote:
> Hello.
> I have another problem.
>
> There is a rule in this steno-writing that makes letters crossed 
> when they are Consonant and Vowel, and there is R in between:
> Eg. (crossing shown as "+")
> *CrV = C+V*
> ekran = ek+an
> prototyp = p+ototyp
> etc.
> *VrC = V+C*
> orka = o+ka
> zerka = ze+ka
> etc.
> It is easy to make a rule for C+V, as in Polish there are only 6 
> vowels that can be crossed, and there is anyway need to make 
> separate glyphs for them. But crossing V+C needs (as there is no 
> need to make separate glyps) to make double rule:
>
> - substitution like clsVow clsR clsCons > clsVow clsCons:(2) _ ;
> - positioning like clsVow clsCons {kern.x = -50m};
>
> But such a kerning rule must not work, when just vowel and consonant 
> meets, it should work only when this pair is made by substitution in 
> context of R.
> I mean, to write something like "orkan", "arka", "zegarka" etc. I 
> need to remove R and move the consonant next to R back to make it 
> crossed with preceeding vowel.
> In docs there is written, that firs all of substitutions are made, 
> then the results are send to positioning part. But this two changes 
> excludes each other: if I first remove R, then resulting pair would 
> not be recognized as R-pair.
> Is it possible to work-around such conflict?
>
> Thanks in advance for Your attention.

Re: [Silgraphite-fonts] Double positioning & substitutioning rule

[Krzysztof S. <fla...@gm...>]

Hello.
Sharon, Your code looks easier to me. Both of them (Sharon's and Martin's)
work. Hint with defining rCross helps me keep code in order. Method no. (2)
would make me define more than 200 pseudo-glyphs (I have a lot of ligatures
of consonants). Now I have to clean my code, as it does not work in every
situation - I suppose, it's because of some mess in the code.
Thank you!

PS. Your hints make me think about redesigning my font to less based on
glyphs to more based on rules. As perhaps in most of alphabets, we can find
returning fragments of glyphs, that can be glued together into complete
glyph by rules of positioning. That might be interesting experiment, and
such a font could be easier to be graphically redesigned, as it would have
to redraw only these parts of glyphs. Of course, first I want to finish
this, what I had begun.


2013/11/12 Sharon Correll <sha...@si...>

>  Hello Krystof,
>
> I'm not 100% sure I understand all the details of your problem, and
> there's something I'm not clear on. You say you are "crossing" the r with a
> vowel or consonant? Does the r actually get totally removed, or just moved
> somewhere? If it is still present nearby in some form, I would expect the
> positioning rule could include it somehow.
>
> Anyway, supposing there is no way to access the r in the positioning rule,
> I can think of a few ways to handle this. (I see that Martin just responded
> with one of these suggestions, but I'll send anyway it since the email is
> already written!).
>
> (1) Use a user-defined slot attribute to record the fact of the crossing,
> and test for it later.
>
> #define rCross user1
>
> table(sub)
> clsVow  clsR  clsCons  >  clsVow  clsCons {rCross = 1};
> endtable;
>
> table(pos)
> clsVow  clsCons_r {kern.x = -50m}  /  _  _ {rCross == 1};
> endtable;
>
>
> (2)  Define pseudo-glyphs that look like the original glyphs, but "know"
> that they need the R-positioning. This is much messier; the advantage is
> that you don't have to do the testing which *can* be slow. I doubt speed is
> a problem for your font, so I'm guessing option (1) above is better for you.
>
> table(glyph)
> gConsB_r = pseudo(unicode(0x0062));  // displays as the default glyph for
> "b"
> gConsC_r = pseudo(unicode(0x0063));
> gConsD_r = pseudo(unicode(0x0064));
> ...
> clsCons_r = (gConsB_r, gConsC_r, gConsD_r, ...);
> endtable;
>
> table(sub)
> clsVow  clsR  clsCons  >  clsVow  _  clsCons_r;
> endtable;
>
> table(pos)
> clsVow  clsCons_r {kern.x = -50m};
> endtable;
>
>
>
> On 11/12/2013 7:52 AM, Krzysztof Smirnow wrote:
>
> Hello.
> I have another problem.
>
>  There is a rule in this steno-writing that makes letters crossed when
> they are Consonant and Vowel, and there is R in between:
> Eg. (crossing shown as "+")
> *CrV = C+V*
>  ekran = ek+an
> prototyp = p+ototyp
> etc.
> *VrC = V+C*
>  orka = o+ka
> zerka = ze+ka
> etc.
> It is easy to make a rule for C+V, as in Polish there are only 6 vowels
> that can be crossed, and there is anyway need to make separate glyphs for
> them. But crossing V+C needs (as there is no need to make separate glyps)
> to make double rule:
>
>  - substitution like clsVow clsR clsCons > clsVow clsCons:(2) _ ;
> - positioning like clsVow clsCons {kern.x = -50m};
>
>  But such a kerning rule must not work, when just vowel and consonant
> meets, it should work only when this pair is made by substitution in
> context of R.
> I mean, to write something like "orkan", "arka", "zegarka" etc. I need to
> remove R and move the consonant next to R back to make it crossed with
> preceeding vowel.
> In docs there is written, that firs all of substitutions are made, then
> the results are send to positioning part. But this two changes excludes
> each other: if I first remove R, then resulting pair would not be
> recognized as R-pair.
> Is it possible to work-around such conflict?
>
>  Thanks in advance for Your attention.
>
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Silgraphite-fonts mailing list
> Sil...@li...
> https://lists.sourceforge.net/lists/listinfo/silgraphite-fonts
>
>


-- 
::| Nondum lingua suum, dextra peregit opus |::
fla...@gm...
* http://www.stenografia.pl *

[Silgraphite-fonts] pseudo glyphs are problematic

[Martin H. <mar...@si...>]

Dear Krzysztof,

> PS. Your hints make me think about redesigning my font to less based on
> glyphs to more based on rules. As perhaps in most of alphabets, we can find
> returning fragments of glyphs, that can be glued together into complete
> glyph by rules of positioning. That might be interesting experiment, and
> such a font could be easier to be graphically redesigned, as it would have
> to redraw only these parts of glyphs. Of course, first I want to finish
> this, what I had begun.

This raises an issue that needs to be more widely understood.

GDL supports the concept of pseudo glyphs, and they can be really useful. But there is a situation where they can become problematic and that is where the pseudo glyph is given a Unicode value. In effect the GDL author is trying to add an entry into the cmap to a pseudo glyph. Given a string of characters containing a character for which there is a pseudo glyph, the graphite engine will do the right thing. The problem is that in the places where Graphite runs, there is also another dynamic going on which is font linking. If a character is missing from a font, the application will take remedial steps either to find a glyph for that one character from another font, or even switch font from there on. The applications often do this without consulting Graphite at all. They look in the cmap of the font, find that there is no entry and so assume the font doesn't support the character. They then break the run at that point and Graphite never gets to see the presumed missing character for it to do pseudoglyph replacement on it.

So my advice is that people not use pseudo-glyphs which specify a Unicode cmap entry. Instead add a dummy glyph to the font and put a real entry in the cmap, using some other tool such as a font editor like fontforge.

Yours,
Martin