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

[Feature Request] Allow optionally enabled rules #664

Open
school510587 opened this issue Nov 13, 2018 · 33 comments
Labels

Comments

@school510587
Copy link
Contributor

@school510587 school510587 commented Nov 13, 2018

According to the discussion among users from Taiwan, I believe frequently used symbols such as emoticons will be defined by zh-tw.ctb (and every ctb table) soon. Especially after NVDA updating its liblouis.dll to UCS4 compatible version, these definitions will be desired by massive users.
However, consider a proposal of defining emoticon braille patterns: https://www.cbtbc.org/braille/emoticons/
It suggests the entire name of an emoticon be present on the braille display, which may be very long. This will cause bad experience for those using 20-cell (or less) braille displays. However, with a 40-cell braille display, a user still hopes to determine what a symbol is.
I think this issue happens universally in every braille table. To satisfy both requests with one ctb table, could liblouis include optionally enabled rules?

@egli

This comment has been minimized.

Copy link
Member

@egli egli commented Nov 14, 2018

Optionally enabled based on what?

  • an additional param in the lou_translate call?
  • another type in the typeform?

Wouldn't a workable and simple solution be to just include the default emoticon definition in the table and have an additional table that defines "short emoticons" (whatever that may be), that overwrites the standard ones. Then you can when invoking lou_translate just pass the normal table or for short emoticons combine the short table with the normal table.

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Nov 14, 2018

Wouldn't a workable and simple solution be to just include the default emoticon definition in the table and have an additional table that defines "short emoticons"

This is exactly what I am thinking. The minimum width of the braille display should be a metadata field, and NVDA should use this to select the right table. It's a bit like how CSS media queries work: https://www.w3.org/TR/css3-mediaqueries/#device-width.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Nov 14, 2018

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Nov 14, 2018

I was not thinking about a universal table. It could indeed be implemented as an "include" table with common emoticon definitions, but every individual table would decide whether it provides a variant that includes the emoticons table or not.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Nov 14, 2018

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Nov 14, 2018

Well kind of. The table discovery mechanism selects only a single, top-level table, and the top-level table decides which sub-tables to include.

So there would be a "zh-tw" table with locale:cmn-TW and, and a "zh-tw-incl-emoji" table which would be identical but would include the emoji definitions and would have an additional metadata field min-ncells:40.

This table discovery mechanism is of course quite rudimentary at the moment. There needs to be one top-level table for each variant of the braille code. The number of tables grows exponentially with the number of optional features. There are ways to improve it, but it is important that the table itself is in control of which sub-tables are included and in which order.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Nov 16, 2018

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Nov 16, 2018

No, it's the first time we're doing something like this. But let's call it min-device-width. That is less cryptic.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Dec 18, 2018

Hi @bertfrees,

I think min-device-width is quite OK. Will it be milestone of the next release? Thanks.

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Dec 18, 2018

There is nothing that needs to be done in the core of Liblouis. You just need to create the tables, and NVDA will need to select the right table based on the properties of the braille display used.

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Apr 14, 2019

There is nothing that needs to be done in the core of Liblouis.

Actually, there needs to be done something in Liblouis to make a query such as device-width:50 match a table with a field min-device-width: 40. This will not magically work at the moment. @school510587 If you are planning to actually create and commit a table with this kind of metadata, like e.g. the emoticons table, then I'm willing to implement it.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Apr 14, 2019

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Apr 14, 2019

I would like to change Liblouis so that it does not require these components to be previously defined.

However it still seems wrong to decompose something that is a single character into two "\x..." characters.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Apr 21, 2019

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Apr 22, 2019

I don't know how to best test Liblouis tables in NVDA. Is there no way to add a new table? Maybe you can just replace an existing table?

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Apr 22, 2019

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Apr 22, 2019

Yeah, sure, if it not possible to add tables to NVDA, you need to put the definitions in the table itself for now. It would be nice if NVDA could make it easier for users to use custom tables though.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Apr 25, 2019

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented May 29, 2019

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented May 29, 2019

I'm working on it but I don't know if it is going to be ready for 3.10. I'll do my best.

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Jun 3, 2019

I'm working on it but I don't know if it is going to be ready for 3.10. I'll do my best.

See #332

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Jun 21, 2019

Is it possible to include this change into 3.10.0 release? If I put emoticons into zh-tw.ctb, I need this feature to avoid a ridiculous number of additional lines.

@school510587 The change was done in Liblouis 3.10. Let me know if it works out for you.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Jun 21, 2019

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Jun 21, 2019

Two different versions is maybe not such a bad option if you can generate one from the other.

The alternative would be that Liblouis, when compiling a table in UCS2 mode, would convert characters in the U+010000 to U+10FFFF range to surrogate pairs. However a limitation is that this will only work for translation rules ("always", "context", etc.), not for character definition rules ("letter", "sign", etc.). And a second issue is that it might be tricky to guarantee that tables behave exactly the same in UCS2 and UCS4 mode. But I think it is doable.

EDIT: It might be possible to support character definition rules after all. But it makes it slightly more complex.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Jun 21, 2019

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Jun 21, 2019

I don't really care about the file names, as long as the metadata is complete. One table should indicate in its metadata that it is intended to be used with a UCS4 version of Liblouis.

For example, a good name for the metadata field could be "bitness", and the possible values "16" and "32" (the former being the default).

Also related is #734, which proposes to put UCS4 tables in a separate folder.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Jun 22, 2019

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Jun 22, 2019

Great.

@DrSooom

This comment has been minimized.

Copy link

@DrSooom DrSooom commented Aug 16, 2019

Please see: nvaccess/nvda#3304, nvaccess/nvda#8702, nvaccess/nvda#9213, nvaccess/nvda#9973, nvaccess/nvda#9982, #688, #689 and https://danielmayr.at/huc/

As Liblouis is also used by embosser software – and not only by screen readers with a connected braille display – I strongly recommend to change the meta tag "min-ncells" to "signnamegrade", which could have eight fixed values – 0 to 7. The end application should have the option to set the detail level of naming for a Unicode character. I don't want that Unicode characters are displayed in a different way automatically due to the length of a braille display. Furthermore I want to read as less cells as possible to recognize a Unicode character. Therefore I invented the HUC Braille Tables at the beginning of 2019.

Here are some examples for the eight signnamegrade values:

  • 0 = shows one single braille character (depending on the configuration for undefined characters; ⠀, ⠿, ⣿, a question mark)
  • 1 = shows the hexadecimal value (Liblouis 3.8 style; '\x266F')
  • 2 = shows the hexadecimal value (HUC8 style; ⣥⡧⠋)
  • 3 = shows the hexadecimal value (HUC6 style; ⠿⠧⠗⠄)
  • 4 = shows the English Unicode name/CLDR of a Unicode character (Music Sharp Sign)
  • 5 = shows the localized Unicode name/CLDR of a Unicode character (Notenschriftzeichen Kreuz)
  • 6 = shows a short (partly new) English name of a Unicode character (Sharp)
  • 7 = shows a short (partly new) localized name of a Unicode character (Kreuz)

Personally I absolutely dislike the idea to replace single Unicode characters with a fixed name in braille automatically due to a table definition. Such replacements MUST be done by the end application itself – before the translation process into braille begins. It would be extremely horrible if "€" and "Euro" are both displayed as ⡑⠥⠗⠕ on a braille display or on paper. That would be a discrimination against the haptic reader in compare to the visual reader, who would still be able to recognize that "€" and "Euro" are different characters with different meanings. Furthermore the haptic reader is no longer able to recognize if "€" and "Euro" is written in the document. So this new produced problem will end in a "€"-"Euro"-mishmash within the same document.

TL;DR: The haptic reader MUST be able to read every single Unicode character exactly the same way as a visual reader does – even if this means that he have to memorize a few hexadecimal values.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Aug 27, 2019

@bertfrees

This comment has been minimized.

Copy link
Member

@bertfrees bertfrees commented Sep 4, 2019

The idea of the min-device-width field was introduced as a way for the table itself to control in which situations it is applicable. In addition we could possibly have some other metadata in the tables to give some more control to the application (or user). But I don't want this other metadata to replace the min-device-width field. As Sponge says, application are free to ignore the min-device-width field.

While in principle your idea of the "signnamegrade" field could work, the 8 values sounds like overkill to me. I can't imagine that there will be tables that will have 8 different versions.

Maybe we should just have a single field to indicate whether special characters like the euro symbol are expanded (e.g. to the word "Euro") or not. All the rest, i.e. rendering undefined characters in the various ways, could be done with pre- and/or post-processing, possibly in combination with some new modes. Note that tables could also just not do these kind of expansions, but the problem is that some braille codes include such rules, so I think it should be the default behavior of those tables.

@school510587

This comment has been minimized.

Copy link
Contributor Author

@school510587 school510587 commented Oct 24, 2019

Hi @bertfrees and @egli,

I have proposed a request to review the representation of emoticons in zh-tw.ctb, but a problem raises now:

Because most users are not familiar to English, it's better to translate emoticons based on Chinese. Here, CLDR is a good choice. Basically, CLDR provides a set of official names in Chinese for all emoticons. However, some characters are pronounced the same in Chinese, some emoticons thus have the same braille pattern using bopomofo-based zh-tw.ctb. Although it is a possible solution that we discuss and determine different Chinese names for these emoticons, some users may feel bad due to inconsistency between braille and speech.

Some reviewer suggests that there should be switch giving the user the entire freedom to choose the braille representation. For example, if this switch is OFF, all characters are displayed using their Unicode value. Previously developed HUC tables by @DrSooom may solve this problem, but I don't know when this feature will be added into NVDA.

Therefore, we conclude to delay the schedule of submission of zh-tw.ctb containing definitions for braille patterns of emoticons, because too early submission will force all users to accept ambiguous braille patterns for emoticons.

However, any opinion is welcome. Thanks!

@egli

This comment has been minimized.

Copy link
Member

@egli egli commented Oct 29, 2019

Hi @school510587 I agree that we should not hastily add such a far reaching new feature to liblouis. I would hesitate to add anything before we have a good understanding of the problem space.

You can always add a feature but it is very hard to remove something once it is established.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.