https://bugs.documentfoundation.org/show_bug.cgi?id=151122
--- Comment #48 from Manu <[email protected]> --- (In reply to Eyal Rozenberg from comment #47) > (In reply to Manu from comment #46) > > Do you > I'm guessing you mean me, since I reported the bug, but it's good to always > mention the name since other people comment as wlll. Sorry, I will be more explicit: "Do you all" At this time of the long discussion, I would like to understand the solution understood by everyone. 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. 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... In my opinion, libreoffice is an openproject, therefore human resources are only voluntary resources and must be used wisely. If we ask for something, and the results is not efficient, and must be changed again, that is not pleasant for everyone. And how to change the rules efficiently if they are not clear? > > Do you confirm each time the user select a new language, then the font list > > must be reanalyzed and repopulated? > > No, it doesn't. The analysis and partition of the list only happens once > (once per LO session or even less than that if we persist the partition). I still don't understand. 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 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? therefore the "font list" for the combobox is reanalyzed (what should be listed) and the combobox is repopulated with the new list. > Also, to the extent that we rely on the font itself to tell us which > language it supports, there's no analysis to begin with. In my knowledge, it is not the case, because the information is not in the format file, but maybe there is new enhancements I don't know? > As for the re-population of the GUI control on the toolbar or sidebar - that > happens now whenever one switches language group; I presume our code clears > the control, then loads a list from somewhere in memory. I thought only the dialogbox Characters was modified. Now I understand also the toolbar and sidebar will be modified. 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? I asked for the time of process and if it can be disabled for the dialogbox. Now I ask the same for the toolbar and the sidebar. > > At this time of the discussion, I don't understand what is a "relax > > heuristic"... > This will be different for different languages. But the general point is: It > is not very difficult (though not entirely trivial either) to devise a > criterion for a font _completely_ covering a language's glyphs. Just mark > all the glyphs that can be used in that language, and if the font has them, > then it's good. But - many fonts are pretty usable, but don't meet this > criteria. You gave the example for French, of fonts without accented > majuscules. So, either 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. And similar decisions need to be made for other > languages. Beyond that, there's the question of individual missing glyphs. > Suppose a font for German has everything except for, say, the glyph for > double-s. And let's even say it exists for regular weight, but missing for > bold. Do we say this typeface doesn't support German? Maybe. We need to set > some policy. > While we don't have a policy for a language, we should fall back on font > self-reporting or per-language Unicode ranges with strict coverage > requirement. 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. My suggestion of a personalized table with unicode ranges is also interesting, because it's clear and it's easy to adapt the ranges for user's needs without new delopment, and it doesn't request to update the font list in dialogbox/toolbar/sidebar each time the text language is modified. But if we want more simple, there is the character list the user set in a textbox. For example, if I set ÇÑÃÕÅßIJŐĞŊŮĆŞΞѢЁЪЂ then the fonts that have these letters could be potentially used for French, Spanish, Portugish, Nordic, German, Netherland, Hungarian, Turkish, Baltic, Slavic, Polish, Romanian, Grec, Russian, Bulgarian, Serbian languages. As a user, this is very simple, I know I want to use this alphabet, I take one letter and put it in this textbox. I want to use two alphabets, I add another letter. I want the special ancient letter, I add it. Nothing complicated. I also suggested some improvements in the lorem ipsum textbox, and even the creation of an alphabet textbox and a personalized lorem ipsum because of different shape problems. So if the team doesn't like these suggestions, and if the time of processing is not a problem, maybe it will be more efficient to use the work of this other project shaperglot? I don't know how many languages they have defined, but at least, they clearly understand the problematic with a clear solution. https://github.com/googlefonts/shaperglot Thanks all for your next comments. -- You are receiving this mail because: You are the assignee for the bug.
