https://bugs.documentfoundation.org/show_bug.cgi?id=151122
--- Comment #49 from Eyal Rozenberg <[email protected]> --- (In reply to Manu from comment #48) > There was many changes, and even if your (Eyal) viewpoint is valuable, I > think other's viewpoints are important, especially the one who will develop > the program code. Yes, certainly, I thought you were talking to me... of course it's in no way my call just because I reported. > https://github.com/googlefonts/shaperglot Oh, that looks really useful! Thanks, Manu! Whether we use that library itself or not, the ideas are certainly relevant, and the heuristic they choose (the examination of aspects of "behavior"). > I can understand that individually we like to use a trial-and-error > (heuristic) method. But in a program code, generally, it does not give good > results... Remember that the other fonts are still all there on the list below the partition. So if our heuristic is not good enough, you can still use whichever font you like. Also, many features or behaviors in LO are not perfect when first released, and feedback from users makes them improve in later releases. Of course we need something "decent" enough to actually be committed in the first place. > For example I set english, then the list would be: > group1: fontEN1 fontEN2 > group2: fontCYR1 fontCYR2 > Later, I set bulgarian, then the list would be: > group1: fontCYR1 fontCYR2 > group2: fontEN1 fontEN2 Yes. But even today, if you switch from English to, say, Hindi - the font list changes, and the combo-box is repopulated. > Therefore, even if the program code analyzed the font files one time and > created a table of font-language compatibilities, the program code needs to > send a query to this table and to repopulate the combobox after we change > the language, isn't it? Well, the query results for different languages are - one would assume - already stored in memory, in some form of another. That is, there will not be a need to run the nested loop "for all fonts for all language glyphs do make sure the glyph is present". > For example, in a multilanguage document with english, bulgarian, and greek, > it means each time I move the cursor in a different paragraph with a > different language, then the list in the toolbar and in the sidebar is > refreshed? Possibly, but not necessarily. It is enough to set the selected item only; and delay the repartitioning until you actually pull-down the list using the arrow button. Another possibility is to have multiple sets of controls, with all being hidden except the ones for the current language. But let the developers tell us what happens in practice. > I dont feel this is so easy if "the developers, or preferably, the French > language community, needs to make the call whether to include such fonts in > the list of fonts-for-French." > It means there will be a full project in order to identify the rules for all > languages... therefore if we want to implement this solution, there will be > a lot of updates in a short and long term. It will be a project, yes. But - not a long-term one. It should involve approaching the different LO language teams: https://wiki.documentfoundation.org/Language_Teams and asking for the input of each one on this matter. Such input will allow switching the criterion for the relevant language from the fall-back (font self-reported, Known Unicode range covering status). Over time, there will probably be some bug reports about the list choices - the handling of which will allow us to refine the partition heuristic further. > But if we want more simple, there is the character list the user set in a > textbox. Assume the user has not typed in any characters; they are just about to do so. Or they are editing a style. What would you use then? > Nothing complicated. That suggestion _will_ actually require some dynamic recomputation (especially if I selected a lot of text on multiple pages); and while it might be simpler to implement and does not require familiarity with languages - it is _quite_ complicated for the user, who will have absolutely no idea what's going on with the partitioned list, which will keep changing for them. -- You are receiving this mail because: You are the assignee for the bug.
