Connecting marks with cursive attachments ?

[Bernie Cossentino]

Hello,

I'm trying to connect marks with cursive attachments in two combinations: mark to mark + cursive or mark to mark to mark + cursive.
In my test font, Bar, ABC and abc are marks while efg are cursive attachments.

Tahoma-test_Font Creator rendering.PNG (4.65 KiB) Viewed 6460 times

Font Creator's rendering engine (above) fooled me into thinking my code works. (The above result is what I need.)
But exporting the view in a web browser (below) reveals quite differently.

Tahoma-test_web browser rendering.PNG (6.52 KiB) Viewed 6460 times

Is Font Creator incorrectly exporting this font, or is my code faulty? If I'm at fault, could any of you point me in the right direction?

To be clear, I don't have the liberty of changing what's assigned as marks and what's assigned as cursive attachments. Otherwise, I would have set all the glyphs in question as cursive attachments and called it a day.

Code is attached below if that helps.

Thank you

Code: Select all

script latn {
  feature MarkToMarkPositioning1;
}

class @ABC_mk [A.mk-C.mk];
class @abc_mk [a.mk-c.mk];
class @ABC [A-C];
class @abc [a-c];
class @def [d-f];

feature MarkToMarkPositioning1 mkmk {
  lookup MarkToMark1;
  lookup MarkToMark2;
  lookup CursiveAttachment1;
  lookup ChainingContext1;
}

lookup MarkToMark1 {
  anchor Anchor_1;
  mark A.mk 0 0;
  mark B.mk 0 0;
  mark C.mk 0 0;
  pos mark bar mark 800 -950;
}

lookup MarkToMark2 {
  anchor Anchor_1;
  mark a.mk 0 0;
  mark b.mk 0 0;
  mark c.mk 0 0;
  pos mark A.mk mark 1300 0;
  pos mark B.mk mark 1300 0;
  pos mark C.mk mark 1350 0;
}

lookup CursiveAttachment1 {
  cursive d entry 0 0;
  cursive e entry 0 0;
  cursive f entry 0 0;
  cursive d exit 1200 0;
  cursive e exit 1200 0;
  cursive f exit 750 0;
  cursive a.mk exit 1100 0;
  cursive b.mk exit 1250 0;
  cursive c.mk exit 1100 0;
  cursive A exit 1300 0;
  cursive B exit 1000 0;
  cursive C exit 1000 0;
  cursive A.mk exit 1300 0;
  cursive B.mk exit 1300 0;
  cursive C.mk exit 1300 0;
}

lookup ChainingContext1 {
  context (bar @ABC_mk) @abc;
  sub 0 SingleSubstitution1;
  context (bar @ABC_mk) @abc (@def);
  sub 0 SingleSubstitution1;
  context (bar) @ABC;
  sub 0 SingleSubstitution1;
  context (bar) @ABC (@def);
  sub 0 SingleSubstitution1;
}

lookup SingleSubstitution1 {
  sub @ABC -> @ABC_mk;
  sub @abc -> @abc_mk;
}

[Erwin Denissen]

We've made numerous changes and improvements to FontCreator, so we strongly recommend to upgrade to the latest version of our font editor.

Please be aware that most text rendering engines will use an advance width of zero for glyphs defined as being a mark, and we are not sure if all support cursive attachment for Latin script characters.

[Bernie Cossentino]

Hello Erwin,

Please be aware that most text rendering engines will use an advance width of zero for glyphs defined as being a mark, and we are not sure if all support cursive attachment for Latin script characters.

Thank you for this. I'm well aware that in-built rendering engines can be a little too kind with font previews. Hence, I prefer to rely on web browser rendering (and the target program where my font will be used) to proof the code.

We've made numerous changes and improvements to FontCreator, so we strongly recommend to upgrade to the latest version of our font editor.

Respectfully, I'm not sure what to make of this...
It doesn't answer my original question as to whether FC v11.5 is buggy and the code is exporting in error (and thus, hindering my progress), or whether my code is at fault.

Assuming FC ver 11.5 is at fault, I don't see how upgrading to the latest version that (assuming) corrects a bug(s) on a version I already own should be at my expense. For the record, I did download the latest version to try. But as you know, I can't export a font in any way to test whether the new version correctly exports my code. So, the above issue remains.

[MikeW]

Well, 11 did come out a couple years ago...And, like you, assuming there is even an issue in FC11...

I would really like it if Adobe, Quark--or Fontlab, Glyphs, etc.--would give me a free copy if & when they ever fixed their bugs that, in some cases, have existed for a decade or more. Heck, I would almost be happy if any of them would comp me from their respective previous versions whenever a bug is fixed in their next versions. I spent more than $2k on upgrades this year (and I haven't upgraded everything). It would mean I never had to purchase another upgrade ever again.

Mike

[honest.bern]

There is a third possibility. W3C establishes standards for web browsers but no browser implements all of them correctly. Sometimes a feature is rendered correctly by the browser on screen but not in print or in the print preview.

It may be that your code is correct, and that FontCreator has processed it correctly, but that this browser makes a mess of this feature.

[Bernie Cossentino]

Well, 11 did come out a couple years ago...And, like you, assuming there is even an issue in FC11...

I would really like it if Adobe, Quark--or Fontlab, Glyphs, etc.--would give me a free copy if & when they ever fixed their bugs that, in some cases, have existed for a decade or more. Heck, I would almost be happy if any of them would comp me from their respective previous versions whenever a bug is fixed in their next versions. I spent more than $2k on upgrades this year (and I haven't upgraded everything). It would mean I never had to purchase another upgrade ever again.

Mike

Thanks Mike,

I'm no stranger to purchasing updates. I fully understand the validity of doing so, even if I feel it's unfair at times. And as I explained above, I don't know whether upgrading to v12 solves my problem.

There is a third possibility. W3C establishes standards for web browsers but no browser implements all of them correctly. Sometimes a feature is rendered correctly by the browser on screen but not in print or in the print preview.

It may be that your code is correct, and that FontCreator has processed it correctly, but that this browser makes a mess of this feature.

Thanks Bern,

Rendering to a web browser (Google Chrome or Firefox) has passed the test every time, prior to using the font in the intended application. This is mostly true because what's rendered by FC is the same in the web browser. But because the difference is so drastic in the above test font, it remains unclear to me whether FC 11 is causing an error in its export.

For those who wish to try it in v11.5 or v12, I've attached the FCP file in my opening post.

Many thanks

[Bernie Cossentino]

And so, I've stumbled on a solution. The web browser rendering is now correct.

Tahoma-test_web browser rendering_ok.PNG (8.73 KiB) Viewed 6387 times

To get this working, I've had to set my marked glyphs as "simple" instead of marks, which I find confusingly contradictory. It would appear, at least with FC, that you cannot connect three consecutive marks and follow them with cursive attachments, at least, its export isn't complying. Does this sound correct to those of you who understand what's going on?

Code and working FCP file is attached if you're curious.

Thanks for checking in.

Code: Select all

script latn {
  feature MarkToMarkPositioning1;
}

class @ABC_mk [A.mk-C.mk];
class @abc_mk [a.mk-c.mk];
class @ABC [A-C];
class @abc [a-c];
class @def [d-f];

feature MarkToMarkPositioning1 mkmk {
  lookup MarkToMark1;
  lookup MarkToMark2;
  lookup ChainingContext1;
  lookup CursiveAttachment1;
}

lookup MarkToMark1 {
  anchor Anchor_1;
  mark A.mk 0 0;
  mark B.mk 0 0;
  mark C.mk 0 0;
  pos mark bar mark 800 -950;
}

lookup MarkToMark2 {
  anchor Anchor_1;
  mark a.mk 0 0;
  mark b.mk 0 0;
  mark c.mk 0 0;
  pos mark bar mark 800 -950;
}

lookup ChainingContext1 {
  context (bar @ABC_mk) @abc;
  sub 0 SingleSubstitution1;
  context (bar @ABC_mk) @abc (@def);
  sub 0 SingleSubstitution1;
  context (bar) @ABC;
  sub 0 SingleSubstitution1;
  context (bar) @ABC (@def);
  sub 0 SingleSubstitution1;
  context (bar) @abc;
  sub 0 SingleSubstitution1;
  context (bar) @abc (@def);
  sub 0 SingleSubstitution1;
}

lookup CursiveAttachment1 {
  cursive d entry 0 0;
  cursive e entry 0 0;
  cursive f entry 0 0;
  cursive a.mk entry 0 0;
  cursive b.mk entry 0 0;
  cursive c.mk entry 0 0;
  cursive a.mk exit 1100 0;
  cursive b.mk exit 1250 0;
  cursive c.mk exit 1100 0;
  cursive A exit 1300 0;
  cursive B exit 1000 0;
  cursive C exit 1000 0;
  cursive A.mk exit 1300 0;
  cursive B.mk exit 1300 0;
  cursive C.mk exit 1300 0;
  cursive d exit 1200 0;
  cursive e exit 1200 0;
  cursive f exit 750 0;
}

lookup SingleSubstitution1 {
  sub @ABC -> @ABC_mk;
  sub @abc -> @abc_mk;
}

[Erwin Denissen]

Your experiments are way beyond what regular users would need, but I'm glad to know you've found a solution.

[Bernie Cossentino]

Your experiments are way beyond what regular users would need, but I'm glad to know you've found a solution.

Thanks Erwin,

I'm not a pro user, that's for sure. So, my methods will certainly come as unorthodox, at best.