This proposal based on a design where users can replace English hyphenation pattern with other language's. It may be natural to set a hyphenation dictionary to each language/script (i.e., set-hyphen-dict : language-tag -> hyphen-dict > ctx -> ctx or set-hyphen-dict : hyphen-dict language-tag-map -> ctx -> ctx) rather than applying given hyphenation pattern globally, if we decide to extend the multi-language system, where English and Japanese are automatically detected with script types.
Introducing new type hyphen-dict
Instead of introducing hyphen-dict and having users explicitly handle hyphenation dictionaries, we could provide primitives get/set strings that represent languages (e.g., set-hyphen-dict : string -> ctx -> ctx).
However, hyphen-dict type allows more extension points (e.g., tweaking hyphenation patterns, adding exceptional words ad hoc) in future.
load-hyphen-dict throwing exceptions
load-hyphen-dict can have signature load-hyphen-dict : string -> hyphen-dict option. I don't have strong opinion about this. I was thinking of having a new package for each language, therefore specifying wrong filenames is unlikely.
Having a primitive to get available hyphenation dictionary files
I could include another primitive get-hyph-dict-list that returns available files under hyph/ (for example, returning [ "en" ]). This primitive is not mandatory.
Renaming english.satysfi-hyph for en.satysfi-hyph
We could leave the filename as is. However, considering even TeX has already adopted naming scheme with BCP 47 Language Tag, there is no reason to stick at traditional naming scheme with language names in English.
This proposal is to add support of hyphenation of non-English languages. This is the first step of supporting internationalization.
Proposal
hyphen-dict
Hyphenation pattern. Underlying OCaml representation isLoadHyph.t
.load-hyphen-dict : string -> hyphen-dict
set-hyphen-dict : hyphen-dict -> ctx -> ctx
get-hyphen-dict : ctx -> hyphen-dict
english.satysfi-hyph
needs to be renamed withen.satysfi-hyph
.load-hyphen-pattern language
loads a hyphenation dictionary fromhyph/<language>.satysfi-hyph
. It raises an exception when the file is not found.set-hyphen-pattern hyph ctx
sets hyphnation patternhyph
toctx.hyphenation_pattern
.get-hyphen-pattern ctx
returns hyphnation patternctx.hyphenation_pattern
.Current Implementation
lib-satysfi/dist/hyph/english.satysfi-hyph
english.satysfi-hyph
is loaded at https://github.com/gfngfn/SATySFi/blob/1243829f9dcaf955e4ba0f5222a0f95b34e74e32/src/frontend/primitives.cppo.ml#L604hyphenation_dictionary
isget_pdf_mode_initial_context
at https://github.com/gfngfn/SATySFi/blob/1243829f9dcaf955e4ba0f5222a0f95b34e74e32/src/frontend/primitives.cppo.ml#L497Alternative Options
Activate multiple
hyphen-dict
s at the same timeThis proposal based on a design where users can replace English hyphenation pattern with other language's. It may be natural to set a hyphenation dictionary to each language/script (i.e.,
set-hyphen-dict : language-tag -> hyphen-dict > ctx -> ctx
orset-hyphen-dict : hyphen-dict language-tag-map -> ctx -> ctx
) rather than applying given hyphenation pattern globally, if we decide to extend the multi-language system, where English and Japanese are automatically detected with script types.Introducing new type
hyphen-dict
Instead of introducing
hyphen-dict
and having users explicitly handle hyphenation dictionaries, we could provide primitives get/set strings that represent languages (e.g.,set-hyphen-dict : string -> ctx -> ctx
).However,
hyphen-dict
type allows more extension points (e.g., tweaking hyphenation patterns, adding exceptional words ad hoc) in future.load-hyphen-dict
throwing exceptionsload-hyphen-dict
can have signatureload-hyphen-dict : string -> hyphen-dict option
. I don't have strong opinion about this. I was thinking of having a new package for each language, therefore specifying wrong filenames is unlikely.Having a primitive to get available hyphenation dictionary files
I could include another primitive
get-hyph-dict-list
that returns available files underhyph/
(for example, returning[ "en" ]
). This primitive is not mandatory.Renaming
english.satysfi-hyph
foren.satysfi-hyph
We could leave the filename as is. However, considering even TeX has already adopted naming scheme with BCP 47 Language Tag, there is no reason to stick at traditional naming scheme with language names in English.