Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatise handling of diacritics #26

Open
2 tasks
snomos opened this issue Jan 24, 2023 · 7 comments
Open
2 tasks

Automatise handling of diacritics #26

snomos opened this issue Jan 24, 2023 · 7 comments
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@snomos
Copy link
Member

snomos commented Jan 24, 2023

This covers two distinct cases:

  • automatise making all non-ASCII chars with diacritics optionally in Unicode NFD (default is NFC) in descriptive analysers, so that we can analyse PDF files without worries - pdf stores all texts in NFD
  • automatise splitting combining diacritic letters (ie those that does not exists as premade NFC's in Unicode) into sequences of base letters + diacritics as individual states in the FST (as opposed to a single, multichar symbol state), for use in tokenisers only, and everywhere else as single-state multichar symbols; this makes input tokenisation on a character level reliable in hfst-tokenise, without resorting to problematic Unicode hacks, but tends to be broken because people forget to make such filters themselves, causing hard-to-debug errors

In the first case, the pseudo code could go something like this:

extract all letter symbols (ie non-multichars)
remove ASCII letters, digits, punctuation
uconv nfc nfd
paste nfc nfd
remove lines with identical columns # e.g. ø and ŋ can't be decomposed
make the result into a XFST regex file for optional change from nfc to nfd
apply the compiled regex to descriptive analysers on the __surface__ side

In the second case, the pseudocode could be something like the following:

extract all multichar symbols from the fst
get rid of everything that looks like tags, flag diacritics and internal symbols
make a regex to mandatorily turn a multichar base letter + (one or more) combining \
    diacritics into a sequence of single symbols
apply that regex to tokeniser FST's on the __surface__ side

With routines like the above integrated into the build system, no-one should ever have to worry about these issues anymore 🙂

@snomos snomos added bug Something isn't working enhancement New feature or request labels Jan 24, 2023
@snomos
Copy link
Member Author

snomos commented Jan 24, 2023

More about the second case:

The reason we want such base letter + combining diacritic as a multichar symbol in all other cases is that it makes life easier to treat things that looks like single letters as actually single symbols even when the underlying Unicode is not a single code point. It is only hfst-tokenise that have issues with this, because of the task at its hand.

@snomos
Copy link
Member Author

snomos commented Feb 17, 2023

Excellent work in commit 573af75. Only problem is: it fails on macOS, probably due to a different version of awk or sed.

@snomos
Copy link
Member Author

snomos commented Feb 17, 2023

Another comment: would it be possible to filter out all non-diacritic characters, to avoid both noise and extra cpu time when compiling and composing the generated regex?

@Trondtr
Copy link
Contributor

Trondtr commented Feb 19, 2023

... it fails on macOS, probably due to a different version of awk or sed.
If this turns out to be a problem, it remains me of a similar situation, which I solved by installing gsed:

/usr/bin/sed
/usr/local/bin/gsed

@flammie
Copy link
Contributor

flammie commented Feb 20, 2023

I changed awk to gawk but not the sed command yet, I think also gnused is used; we have a configure script in langs for checking that could be useful but not sure if everyone runs configure in core even

@snomos
Copy link
Member Author

snomos commented Feb 20, 2023

One has to run ./configure in core, to get the correct version info. But the tools in core doesn't carry automatically over to each language, so we need to run the same check there.

@flammie
Copy link
Contributor

flammie commented Feb 20, 2023

mmh I have now some checks in core for gnu sed and gawk and the unicode filter scripts use the configured programs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants