With version 4.0.0 8f0540a on Windows 7 HP 64 with Java 1.8.0_74, the aggressive font fallback works fine in the Edit pane but not in the Search results.
Yes, it shows blocks if A.F.F. is off in 4.0.0, but in 3.5.3 the Japanese characters display correctly in the Edit field even if A.F.F. is off. The only difference between 4.0.0 and 3.5.3. on my computer is that 3.5.3 is installed (and I use OmegaT.exe to run it) , whereas 4.0.0 is run from a temporary folder on my Desktop (and I simpy double-click OmegaT.jar to run it).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is bizarre. It took a while but I was able to narrow down the cause to commit r8391 where I added the Segment Properties pane. For no apparent reason, setting the font on the Table View of this pane causes font fallback to break on Windows.
I note that even prior to the introduction of this pane, Windows seems to have very fragile font fallback: With Japanese text in the Editor, even if the text shows up correctly on project load, merely changing the font size when the selected font does not have Japanese glyphs will cause the text to turn into "tofu".
For the moment, a workaround for tofu-on-project-load is to set the Segment Properties pane to use the List View. If the Segment Properties pane is not visible, do Options > Restore Main Window, then un-minimize the pane and use its settings menu (the gear icon) to select List View. It's not clear why this works, but it allows normal fallback in both the Editor and the Search window's results area.
Last edit: Aaron Madlon-Kay 2016-04-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Font fallback is applied to search results as of r8651. The change in font fallback behavior between 3.5.3 and 4.0.0 is a separate issue and is a bug, but it's not clear whether it's our problem or a Java problem. Ticket: [bugs:#808]
Japanese text should not need aggressive font fallback to begin with. Does the editor really show squares when font fallback is off?
Yes, it shows blocks if A.F.F. is off in 4.0.0, but in 3.5.3 the Japanese characters display correctly in the Edit field even if A.F.F. is off. The only difference between 4.0.0 and 3.5.3. on my computer is that 3.5.3 is installed (and I use OmegaT.exe to run it) , whereas 4.0.0 is run from a temporary folder on my Desktop (and I simpy double-click OmegaT.jar to run it).
This is bizarre. It took a while but I was able to narrow down the cause to commit
r8391where I added the Segment Properties pane. For no apparent reason, setting the font on the Table View of this pane causes font fallback to break on Windows.I note that even prior to the introduction of this pane, Windows seems to have very fragile font fallback: With Japanese text in the Editor, even if the text shows up correctly on project load, merely changing the font size when the selected font does not have Japanese glyphs will cause the text to turn into "tofu".
For the moment, a workaround for tofu-on-project-load is to set the Segment Properties pane to use the List View. If the Segment Properties pane is not visible, do
Options > Restore Main Window, then un-minimize the pane and use its settings menu (the gear icon) to selectList View. It's not clear why this works, but it allows normal fallback in both the Editor and the Search window's results area.Last edit: Aaron Madlon-Kay 2016-04-04
Ticket moved from /p/omegat/bugs/807/
Aggressive font fallback was never applied to the Search window's results pane. It's not a bug, so moving to RFE.
Font fallback is applied to search results as of r8651. The change in font fallback behavior between 3.5.3 and 4.0.0 is a separate issue and is a bug, but it's not clear whether it's our problem or a Java problem. Ticket: [bugs:#808]
Related
Bugs:
#808Last edit: Aaron Madlon-Kay 2016-04-05
Implemented in the released version 4.0 of OmegaT.
Didier