On 15.05.17 10:44, Jean-Marc Lasgouttes wrote: > Le 14/05/2017 à 21:23, Stephan Witt a écrit : >> I tried to get some numbers. The numbers I got with Instruments were unclear. >> The time to go through the english users guide with and w/o the patch is the >> same. >> The time to go through the hebrew tutorial is not very different. >> I’ll attach the profiler runs focussing on QTextLayout::endLayout for hebrew. > > I happened to push the commit by inadvertance. This is probably a good > idea, let's see. > > I'd like neverthless to understand the precise problem. Mike, did the > problem exist for you only for Ancient Hebrew? Can you describe for us > what is so special about ancient Hebrew? Do you know of other languages > that should create similar problems? > > What I have in mind is that we might be able to restrict the use of > caching to some specific fonts. How would I recognize a font used for > ancient Hebrew? >
First line to tackle would appear to be that LyX on OS X is just slower. But I do not know how much Qt or LyX itself are to blame for this. Boot linux on the same machine and see a faster and smoother LyX. Use it in a linux-VM and see a faster LyX, despite the overhead. This is not restricted to any special language needs or scripts. But then again in my experience other Qt-apps also suffer from this to varying degrees. None of which, I suppose, I use to type text on OS X. Maybe that's why I come to feel LyX as the worst offender there on OS X. What it makes so special – from a technical or programming view – to try to use ancient Hebrew I can only guess: Ancient Hebrew is RTL, uses special and imperfect unicode features to generate ַand place the vocals and accents on, in, under and around the consonants. Modern Hebrew usually does not use the vocals. So this would not appear as much of a problem there. If you try to emulate the exact massoretic vocalization of certain parts of the text there are some portions so seemingly arbitrarily vocalized (and too complex for unicode) that even ancient and modern scribes have had difficulties placing the dots and strokes the right way. But these problems are few, the slowness starts without them. Perhaps these documents may help you understand a bit better: http://www.brill.com/files/brill.nl/special_scripts_hebrew_transliteration_scholarly.pdf https://www.sbl-site.org/fonts/biblicalhebrewtiromanual.pdf Since I also find Arabic to be quite painful to use in LyX and this script is also RTL and relies on context-sensitive letter-forms, my further guesses in this direction would suggest to look for all languages that might do something similar, like Sanskrit, Gujarat, Chinese, Hangul, Devanagari and so on (as far as they are claimed to be supported by LyX) Interestingly I just tried to set a latin OpenType font with complex contextual alternatives as a screen font that emulates handwriting and found that LyX just ignores all of these otf features. So it might be unicode and/or OpenType related? Since I struggled just yesterday to do something reasonable with the Arabic docs: I noticed that Sheherazade font works so easily for the LyX-docs is because it contains glyphs for Arabic and Latin; while my other fonts are usually one or the other. After much trial and only errors I just failed to declare proper fonts, scripts and languages in LyX for use with XeTeX and Arabic and gave up the fight for another day. What is ultimately needed there was discussed a while ago: LyX should be better at providing for multilingual documents and offer a way to declare different fonts for different scripts. A glimpse of what's needed can be seen here: https://www.guyrutenberg.com/2015/03/21/creating-a-hebrew-document-in-lyx-2-1-with-xetex/ Then you just have to recognize that the user tells you that it is text intended for a certain language/script and that he calls for that font. greetings Mike
