User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Build Identifier: version 5.2.1.2 Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 I am typing Tai Dam language text using the Tai Heritage Pro 2.5 font (http://scripts.sil.org/taiheritage). I have also observed this behavior with a Miao font that is still under development. I select the font and start typing. When I reach the second word, it is displayed over top of the first word. Each successive word is displayed at the beginning of the line, so all the words overlap. I am also using Keyman 9 with the Tai Dam US Mnemonic keyboard (http://scripts.sil.org/TaiDamKeyboards). Reproducible: Always Steps to Reproduce: 1. Launch Writer 2. Select the Tai Heritage Pro font. 3. Select the Tai Dam keybaord. 4. type several words. 5. Hilight the text you just typed. You will see that LO now displays the font as Lucida Sans. 6. Change the font to Tai Heritage Pro, and the text will display correctly. Expected Results: See attachment. Reset User Profile?No
Created attachment 127769 [details] Screen shot of how text is displayed, incorrect vs correct.
Are you 100% sure that the font complies with international standards? Does it work right in other software? Also can you please attach an actual document and include the font in the file. Probably you'll have to upload to a third party and then link. Embed Fonts: https://help.libreoffice.org/Common/Embedding_Fonts Set to UNCONFIRMED once you attach.
Please disable OpenGL render (Tools -> Options -> View: "Use OpenGL for all rendering (on restart)" check box in the Graphics output section. Any improvement in the text layout?
(In reply to V Stuart Foote from comment #3) > Please disable OpenGL render (Tools -> Options -> View: "Use OpenGL for all > rendering (on restart)" check box in the Graphics output section. > > Any improvement in the text layout? No. OpenGL was already off. I tried turning it on, exited, restarted, turned it off, exited and restarted again. There was no improvement.
(In reply to Joel Madero from comment #2) > Are you 100% sure that the font complies with international standards? Does > it work right in other software? > > Also can you please attach an actual document and include the font in the > file. Probably you'll have to upload to a third party and then link. Embed > Fonts: https://help.libreoffice.org/Common/Embedding_Fonts > > Set to UNCONFIRMED once you attach. I built the font 4 years ago. It passed Font Validator. Also, it has worked in past versions of LO, and in other Graphite applications, including XeTeX, FireFox, and Thunderbird. I'm not sure how to attach a file to this comment. I'll save it and then attach a file to a new comment.
The file was too large. I haven't been able to upload it.
So is this a Graphite shaping based font? What was the last build of LibreOffice that the fonts rendered correctly for you?
lets try that with the correct META bug 71732
(In reply to V Stuart Foote from comment #7) > So is this a Graphite shaping based font? What was the last build of > LibreOffice that the fonts rendered correctly for you? Yes, it is a Graphite font.
Looks like a duplicate of bug 72940.
(In reply to Joel Madero from comment #2) > Are you 100% sure that the font complies with international standards? Does > it work right in other software? > > Also can you please attach an actual document and include the font in the > file. Probably you'll have to upload to a third party and then link. Embed > Fonts: https://help.libreoffice.org/Common/Embedding_Fonts > > Set to UNCONFIRMED once you attach. Sorry for the delay. Here's a link to a data file with embedded font. https://drive.google.com/open?id=0By5sfkbjuePFOG1VTE5jUDlaUTg
(In reply to V Stuart Foote from comment #7) > So is this a Graphite shaping based font? What was the last build of > LibreOffice that the fonts rendered correctly for you? I had to go back and check. It worked OK in 5.0.5.2 Build ID: 55b006a02d247b5f7215fc6ea0fde844b30035b3 It failed in 5.1.0.3 Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
Jim, * Looking at your sample document, the font is embedded fine, but checking the paragraph style notice that your "default" paragraph is styled for CTL scripts to use Lucida Sans When I edit the default paragraph and use the Thai Heritage Pro as CTL font and set Thai language for the CTL values--the paragraphs render using the expected font. Including new paragraphs. Not sure about the fall-back (Lucida Sans of course has no glyph coverage of these code-points) issue of comment 0 with Graphite font fallback--bug 72940--have those been resolved--or is overwriting still happening? Anyhow, if you edit the default paragraph or use a paragraph style that has the CTL font set correctly--does that behave better with your IME?
FYI: My system has upgraded to LO 5.2.2.2. The comments below are based on that version. Re #13: I first had to go to Tools/Options/Language Settings/Languages, and check the box for "Complex text layout(CTL)". (Until I did that, the CTL font didn't show up in the style definition dialogue.) I then had to select a language, Lao being the closest to what I'm working with. I tried both Lao and "None". I then was able to edit the default style, selecting Tai Heritage Pro as my CTL font. After that, I was able to enter Tai text using the Tai Heritage Pro font, and it displayed correctly--until I tried to switch to a different CTL font. For example, I tried using a font called TaiViet, but LO insisted on entering and displaying the text using Tai Heritage Pro. Likewise when I tried entering Cham text using the Cham East BinhThuan font. I had to first type the text, then select it and apply the font. That's hard to do when all you see are square boxes while you are typing. After that, I couldn't get back to Tai Heritage Pro without again typing the text first, then selecting the text and applying the font. When I select a Roman font, the change is made smoothly. Why does LO have to be so cranky about changing a CTL font?