Jump to content
You must now use your email address to sign in [click for more info] ×

Occasional glitch with overwrite character choosing wrong glyph


Recommended Posts

On three or four occasions, I have encountered an odd problem, which unfortunately I cannot reproduce at will.  I have some math expressions involving subscripts.  Rarely, when I select a subscript character and type an "i" on top of it (to change the old subscript to an "i"), I get a dotless i displayed.  I cannot say if this is the actual Unicode dotless i glyph (U+0131) or a display glitch.  Once this happens, if I type an "i" or a "j" on top of the affected character, I continue to see the appearance of dotless i or dotless j (U+0237).  If I type another character ("k" is the one I normally try), then I get the expected glyph and the weird behavior ends.  Specifically, if I then type an "i" or a "j" on top of the previously affected character, I get the regular i or j glyphs, not the dotless ones.

It should be really obvious, but I will state it explicitly just to be painfully clear.  I am not changing stylistic sets or other typography settings when writing a character on top of an existing subscript character.

The "subscript" characters are implemented through a character style involving font size reduction and baseline offset, not by use of the subscript OpenType feature.  Preceding and following characters are generally in a different character style.  Font is typically Cambria.

Almost all the time, typing an "i" on top of an existing subscript does the right thing.  So this problem is rare, but common enough to recognize as "oh, that's happening again".

I saw this problem with the Publisher 1.8 series, and saw it again with 1.9.1 recently.

Link to comment
Share on other sites

Cambria has an OpenType feature which replaces the i and the j with the dotless forms when they are followed by a combining mark.
So that is probably what is happening.
What is the following character when this happens?
To tell whether or not that is an OpenType shaping engine bug in APub we would have to see exactly what is happening.

Cambria does actually have i inferior and j inferior characters, but they are not included in the OpenType Subscript code.
iinferior =1D62
jinferior = 2C7C

Because of the way you have created the subscript characters, they are still an i and a j (in Unicode).
So when you type them that is the Unicode code point used - and what is going to be replaced.
Depending on what the following character is, that may be an error in the APub shaping engine.
Like I mentioned above, really have to see exactly what is happening to see if this is a bug.

Link to comment
Share on other sites

I will try to capture the information about the following character(s) the next time this happens, and update this thread.  From the specifics of this particular document, it is most likely to be a thin space, a plus or a minus (not a hyphen).  I just now discovered Text > Toggle Unicode, which will give me confidence that what I report is accurate.

Because it usually does not happen, it's probably not as simple as "if following character is x, then mess up".  But maybe we can figure it out.

Link to comment
Share on other sites

20 minutes ago, sfriedberg said:

Because it usually does not happen, it's probably not as simple as "if following character is x, then mess up".  But maybe we can figure it out.

Yes, I also think that is the case ... as I was trying to figure-out how that sequence of characters could be in your math text.
Since I assumed that to be unlikely, it would seem to be a bug.
My current SWAG is that it may also be happening with other "types" of characters not in the correct list.
The "correct list" being an OpenType character class defined in the font OpenType code (a list of 106 combining characters).
It may be getting confused by the sequence of edits, but that should not happen.
Need to see some of the actual text to test.

p.s. intermittent issues are the worst ;-)

Link to comment
Share on other sites

These are the characters/glyphs which should trigger the replacement of the i with the dotless i.

class @MarkAttachmentClass1 [gravecomb acutecomb circumflexcomb caroncomb tildecomb dieresiscomb macroncomb brevecomb ringcomb doubleacutecomb dotaccentcomb turnedcommacomb glyph646 greekdialytikatonoscomb glyph814 overlinecomb verticallinecomb doubleverticallinecomb doublegravecomb candrabinducomb invertedbrevecomb glyph1198 glyph1199 leftangleabovecomb xabovecomb verticaltildecomb doubleoverlinecomb gravetonemarkcomb acutetonemarkcomb greekperispomenicomb greekkoroniscomb bridgecomb nottildecomb homotheticcomb almostequaltocomb rightarrowheadcomb lefthalfringcomb fermatacomb righthalfringcomb acomb ecomb icomb ocomb ucomb ccomb dcomb hcomb mcomb rcomb tcomb vcomb xcomb hookcomb glyph4727 glyph4729 glyph4731 glyph4733 glyph4735 glyph4737 glyph4739 glyph4741 dotaboverightcomb zigzagcomb dottedgravecomb dottedacutecomb suspensionmarkcomb macronacutecomb gravemacroncomb macrongravecomb acutemacroncomb graveacutegravecomb acutegraveacutecomb leftarrowheadcomb glyph5561 glyph5563 glyph5565 glyph5567 glyph5569 glyph5571 glyph5573 glyph5575 glyph5577 glyph5578 glyph5579 glyph5580 glyph5581 glyph5583 glyph5584 glyph5585 glyph5586 glyph5587 glyph5588 glyph5589 glyph5590 glyph5591 glyph5592 glyph5593 glyph5594 "titlocomb-cyrl" "palatalizationcomb-cyrl" cyrillicdasiapneumatacomb cyrillicpsilipneumatacomb glyph6854 "pokrytiecomb-cyrl" commacomb reversedcommacomb];
Quote

class @MarkAttachmentClass1 [gravecomb acutecomb circumflexcomb caroncomb tildecomb dieresiscomb macroncomb brevecomb ringcomb doubleacutecomb dotaccentcomb turnedcommacomb glyph646 greekdialytikatonoscomb glyph814 overlinecomb verticallinecomb doubleverticallinecomb doublegravecomb candrabinducomb invertedbrevecomb glyph1198 glyph1199 leftangleabovecomb xabovecomb verticaltildecomb doubleoverlinecomb gravetonemarkcomb acutetonemarkcomb greekperispomenicomb greekkoroniscomb bridgecomb nottildecomb homotheticcomb almostequaltocomb rightarrowheadcomb lefthalfringcomb fermatacomb righthalfringcomb acomb ecomb icomb ocomb ucomb ccomb dcomb hcomb mcomb rcomb tcomb vcomb xcomb hookcomb glyph4727 glyph4729 glyph4731 glyph4733 glyph4735 glyph4737 glyph4739 glyph4741 dotaboverightcomb zigzagcomb dottedgravecomb dottedacutecomb suspensionmarkcomb macronacutecomb gravemacroncomb macrongravecomb acutemacroncomb graveacutegravecomb acutegraveacutecomb leftarrowheadcomb glyph5561 glyph5563 glyph5565 glyph5567 glyph5569 glyph5571 glyph5573 glyph5575 glyph5577 glyph5578 glyph5579 glyph5580 glyph5581 glyph5583 glyph5584 glyph5585 glyph5586 glyph5587 glyph5588 glyph5589 glyph5590 glyph5591 glyph5592 glyph5593 glyph5594 "titlocomb-cyrl" "palatalizationcomb-cyrl" cyrillicdasiapneumatacomb cyrillicpsilipneumatacomb glyph6854 "pokrytiecomb-cyrl" commacomb reversedcommacomb];

That is a bit easier to scan than the code block.

Link to comment
Share on other sites

Well, this happened again this afternoon, and this time overwriting a 'k' did not clean up the problem.

The affected character was U+0069 ('i').  It was followed by U+2009 (thin space) and U+2219 (bullet operator).  I am pretty sure I have seen it with other following characters such as plus and minus, but cannot be absolutely certain.  In this specific situation, the thin space had default ([No Style]) character styling, while the affected character had a character style assigned with a font size reduction and a baseline adjustment.

Toggling Unicode on the affected character did not clean up the problem, but toggling Unicode on the thin space replaced the dotless i glyph with the expected dotted i.  Toggling Unicode off the thin space restored the unwanted dotless i glyph.  I could repeat this indefinitely.

I inserted a zero-width space immediately after the affected character, in its character styling span, and that cleaned up the display, restoring the expected dotted i.

I have very many occurrences of these exact sequences of characters and character stylings, a great many of them cut-and-paste from earlier occurrences.  (This motivated my earlier request for adding styled text snippets as an asset type, but that's neither here nor there.)  It is significant that most of the occurrences don't show the problem, and that I see the problem only rarely when making edits by overwriting characters.

To generate proper math expressions (or at least as close as AffPub can come right now), I am changing character styles on practically every character in the affected sequences.  In addition to characters with explicit character styles assigned, I have many characters with a character style and a local (non-styled) override.  It would not surprise me at all if the transitions between character styles are contributing to triggering the problem.

Some experiments that did not occur to me, which I will attempt the next time I encounter the problem, include 1) typing additional characters before the affected character in a span of the same character styling and local overrides, and 2) deleting the affected character entirely followed by inserting it in the styling span of the preceding character then restyling the newly inserted character.

If an Affinity staff member (eventually) sees this, is there any value to saving a copy of my document at a moment when I have the problem?  My impression is that this is a transient display issue that would not be captured in a saved file, but perhaps that's too pessimistic.

Link to comment
Share on other sites

@sfriedberg

On my phone and have not been able to test today ... I wonder if APub is treating the thin space like it is a narrow no-break space which does have some combining qualities. There was some discussion about treating it the same way as it is done in InDesign.

Which I see as - if InDesign does something stupid we should also do it.

I consider it a bug. It does not comply with the Unicode standard, or work as expected.

Until I can test I cannot see if this is what is happening. Maybe tomorrow.

Discussion was here:

@Dave Harris is the Affinity OpenType guy.

We need to get him to discuss this here.

I hope this is not what is happening, but it could explain what you are experiencing. 

Link to comment
Share on other sites

15 hours ago, sfriedberg said:

Inserting a zero-width space did clear up the last occurence, so I will try some others

Yes, that is the common way to break unwanted OpenType character combinations. APub has no way to disable the OpenType ccmp feature (which is what is doing this), so for me to document a font this is the only annoying workaround. This is easy in LibreOffice so until APub enables disabling ccmp, and annoying things like fake small caps, I will keep using LO.

Will test this later today.

Link to comment
Share on other sites

@sfriedberg

Hmmmm ... testing with Cambria (regular not Math)... and not seeing that behavior. (edit: also tried Math, same result)
Tried with the thin space and the narrow no-break space - no change in the i.
Tested with the combo you mentioned above:

On 4/5/2021 at 9:32 PM, sfriedberg said:

The affected character was U+0069 ('i').  It was followed by U+2009 (thin space) and U+2219 (bullet operator).

No change in the i.

Tested with the i and the combining acute accent - works as expected - dotless i with an acute above.

So I am perplexed.

What language is set on the text?  Should not matter based on the way the font is built, but I am guessing.

Probably going to have to see your actual doc.

Link to comment
Share on other sites

Languages are all unchanged from a default install on an English language Windows system.  General preference language is English (United States).  Character > Language: Spelling is English (United States).  Character > Language: Typography language is Auto.  Character > Language: Hyphenation language is Auto.

If I had to make a guess, I would guess this affects about 1% of my expressions involving a subscript or superscript i, and it does not always affect an expression which previously had the problem.  Furthermore, it I can get the problem to stop (without ultimately inserting or changing any characters from the originally affected sequence), then when I save the file and reopen it, the problem stays stopped.  So it's not going to be easy to reproduce.  When I have more time, I will attempt to strip out 99% of the document text and all the illustrations and see if I can get the problem to recur with a smaller file.

Link to comment
Share on other sites

Are you bringing this text in from another document?
From another application?
If that is the case, there could be hidden characters included in the text.
And saving the document may strip-out those hidden characters.

Where is this text coming from?
If you are typing it in that shoots down this theory.

Link to comment
Share on other sites

OK.
Since the tests I did worked correctly...
And the text is being typed-in...
Then this appears to be a bug triggered by some particular sequence of input and direct formatting.
That would appear make it definitely a bug.
Should not be happening.
But it is going to be really hard to find until it can be replicated.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.