Skip to content

Conversation

@mkorje
Copy link
Collaborator

@mkorje mkorje commented Jan 14, 2026

Mappings

See the image below for the current behaviour:

arabic-math-style
Typst code
#set page(width: auto)

#show math.equation: set text(font: "Noto Sans Math")

// You can use the Arabic characters directly, these are just for my convenience.
#let abjad = $
  alef
  beh
  beh.dotless
  jeem
  dal
  heh
  waw
  zain
  hah
  tah
  yeh
  kaf
  lam
  meem
  noon
  noon.dotless
  seen
  ain
  feh
  feh.dotless
  sad
  qaf
  qaf.dotless
  reh
  sheen
  teh
  theh
  khah
  dad
  zah
  ghain
$

Upright (normal):
$ upright(abjad) $

Default (isolated for all except `jeem` and `heh`, which are initial): \
TODO: `beh` and `jeem` should go to their dotless forms...
$ abjad $

Double-struck (falls back to default):
$ bb(abjad) $

Isolated (falls back to default):
$ isolated(abjad) $

Initial (falls back to default):
$ initial(abjad) $

Tailed (falls back to default):
$ tailed(abjad) $

Stretched (falls back to default):
$ stretched(abjad) $

Looped (falls back to default):
$ looped(abjad) $

Questions

  1. Are there better names for these functions? I.e. are there common shortenings similar to the current styles: "frak" (fraktur), "cal" (calligraphic), "bb" (double-struck), etc.

  2. The default mapping for beh and jeem should be their dotless form (the dotless form of beh is beh.dotless but the dotless form of jeem is just hah). The issue (from an email I sent to @khaledhosny last year):

Would a user ever want the dotted forms of beh and jeem then? I figure there should be some way for the user to get them in math mode if they wanted. This is where I'm struggling to come up with good UX; it doesn't seem to fit as nicely as the other Arabic styles and Latin/Greek styles.

The dotted beh has most styles, whereas the dotless one lacks them (I think the only style it has is the stretched, but then this could cause problems as which one should be picked?). I would guess that inputting $bb(ب)$ ought to give the double-struck dotted beh, and not try to give a double-struck dotless beh (which doesn't exist, and so will fallback to an isolated dotless beh). The simplest thing would be to ignore that, so if a user inputs
$ب upright(ب) bb(ب) stretched(ب) ٮ upright(ٮ) bb(ٮ) stretched(ٮ)$
they get
$𞸜 ٮ 𞸜 𞹼$ x2

Khaled suggested to do the automatic mapping in the first case only and maybe have another function (e.g. default()) that corresponds to the automatic mode. Alternatively, do away with the automatic mapping and make sure users can reconfigure the mapping between the base Arabic block and math block.

And maybe then
$dotted(ب) upright(dotted(ب)) bb(dotted(ب)) stretched(dotted(ب))$
gives
$𞸁 ب 𞺡 𞹡$

Mapping jeem to hah by default should be fine, especially since they both have variants in all the Arabic styles. I'm guessing I should also add that hah has the default be initial instead of isolated, just like jeem. So if a user types
$ج stretched(ج) isolated(ج) upright(ج) ح stretched(ح) isolated(ح) upright(ح)$
it ends up as
$𞸧 𞹧 𞸇 ح$ x2
Maybe then
$dotted(ج) stretched(dotted(ج)) isolated(dotted(ج)) upright(dotted(ج))$
gives
$𞸷 𞹢 𞸂 ج$

@dccsillag
Copy link
Collaborator

dccsillag commented Jan 14, 2026

I think we have to be a little careful here, particularly with potential 'intersections' between these new Arabic letters and the (existing!) Hebrew letters. For example, in some parts of the world alef (which here is being added as an Arabic symbol) is how one would spell aleph (as in the Hebrew letter). If we were to add the rest of the Hebrew alphabet as well, then there would be even more clashes (sometimes even of the exact same name).

As an aside, I don't think I've ever seen these in math. Do you have some particular use in mind? Having a clear use-case might help come up with ways to work around the clashes.

@mkorje
Copy link
Collaborator Author

mkorje commented Jan 14, 2026

For example, in some parts of the world alef (which here is being added as an Arabic symbol) is how one would spell aleph (as in the Hebrew letter)

We used to have both spellings, but ended up deprecating the ones that we thought were more uncommon (see #61).

If we were to add the rest of the Hebrew alphabet as well, then there would be even more clashes (sometimes even of the exact same name).

I can't find the conversation, but because the other Hebrew letters don't have equivalent LTR mathematical forms and aren't used in math, there is no intention of adding them. While the Arabic ones aren't used either in the English speaking math world, they are used for RTL Arabic mathematics and have mathematical forms and other styles (with dedicated codepoints), much like the Latin and Greek alphabets.

Though I'm not sure whether the added names would ever be used by those writing RTL mathematics in Arabic. For now it makes my life easier accessing the characters while I'm working on implementing RTL math 😅. I can always drop that commit later.

@MDLC01
Copy link
Collaborator

MDLC01 commented Jan 14, 2026

Though I'm not sure whether the added names would ever be used by those writing RTL mathematics in Arabic. For now it makes my life easier accessing the characters while I'm working on implementing RTL math 😅. I can always drop that commit later.

I agree those names should be dropped before merging this PR.

@khaledhosny
Copy link

Having a way to access symbols by name can be very handy, since other math commands/names/whatever it is called are English words (LTR) and mixing them with Arabic letters (RTL) can make editing the text really complicated.

@MDLC01
Copy link
Collaborator

MDLC01 commented Jan 14, 2026

This is probably a decision that would have to be made by the Typst team, but what about using Arabic for those functions (only the version that is exposed to the Typst user, not the rust implementation)? To me this seems like the best solution, also because the names are currently quite generic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants