Apache OpenOffice (AOO) Bugzilla – Issue 85422
Text-to-text alignment Middle does not lay Asian characters in the middle.
Last modified: 2017-05-20 11:15:45 UTC
Phenomenon: With OpenOffice.org 2.3 Asian characters in various font size are not laid in the middle of line under Text-to-text alignment Middle in vertical writing. Additionally, Text-to-text alignment Top or Bottom does not work appropriately. For details, see a snapshot. Quick investigation: When the module vcl provides information on geometrics of a glyph, the vcl seems to return an artificial leading for Asian glyphs, which is calculated with an equation like "0.30 * (Ascent + Decent)." vcl/win/source/gdi/salgdi3.cxx void WinSalGraphics::GetFontMetric( ImplFontMetricData* pMetric ) { ... // #110641# external leading for Asian fonts. // The factor 0.3 has been confirmed with experiments. long nCJKExtLeading = static_cast<long>(0.30 * (pMetric->mnAscent + pMetric->mnDescent)); nCJKExtLeading -= pMetric->mnExtLeading; pMetric->mnExtLeading = (nCJKExtLeading > 0) ? nCJKExtLeading : 0; The following source files also have the similar code fragments: vcl/aqua/source/gdi/salgdi.cxx vcl/source/glyphs/gcach_ftyp.cxx Quick experiment: Applying a patch to some methods in the module vcl in order to cancel the artificial leading, Writer becomes to lay Asian characters in an appropriate way. For details, see an experimental patch for the module vcl. The patch, however, has a side effect. Distances between lines become smaller than before applying the patch. But, it could be said that having no artificial leading is better than having such a somewhat unexpected leading because the amount of leading is designed by font designers. Solution: Further discussion might be needed to have better specifications and implementation.
Created attachment 51033 [details] A sample bugdoc
Created attachment 51034 [details] Snapshots with 2.3.0 plus patch, 2.3.0, and 680m242
Created attachment 51037 [details] An experimental patch for the module vcl
fme->tora: Thank you for your patch. I think this needs some more work for two reasons: 1. This patch also sets the leading values for non-Asian text to 0 and 2. For Asian text, the changed leading values would result in layout changes for existing documents. Please discuss this with the vcl team.
The magic with the factor 0.3 was introduced for issue #110641# with http://gsl.openoffice.org/source/browse/gsl/vcl/win/source/gdi/salgdi3.cxx? r1=1.47.14.2&r2=1.47.14.5 I agree that the font's metrics should always be preferred, so it was implemented like this originally. But legacy apps obviously used the 30% heuristic and CJK-fonts were designed for these mainstream apps... Anyway, as far as I know nothing in VCL changed for top-/bottom-alignment between OOG680 and SRC680_m242. @FME: weren't some grid-layout changes in SW in this timeframe? That the small latin characters in the bugdoc seem to move downwards come from the fact, that top- alignment means alignment of the "logical top" as opposed to "ink-top". Do any other productivity suites use the other method?
@HDU: [...] weren't some grid-layout changes in SW in this timeframe? [...] No. @Tora: What about taking the external leading into consideration while calculating the line height, but ignoring the external leading for the vertical alignment of (Asian) text portions?
@fme: That is a good idea. So, how about the following approach? 1. Determine the maximum value of leading within a line. 2. The height of line will be changed from ascent+decent+leading to only ascent+decent. The maximum value of leading will be kept separately. 3. At the very end of process for calculating a position of line, the separately kept maximum value of leading will be inserted after most of the calculations for text layout is accomplished.
fme->tora: The important point is that the line size is *not* allowed to change because of layout compatibility. So the line size calculation may not change! But the alignment calculation of the text portions can be adjusted. Please check if this is feasible.
tora->fme: I see. You have a point. Here is an experimental patch that I have created following your suggestion. In short, the patch is designed in the following way: 1. Adds GetLeading() and similar method besides existing Height() and GetAscent() in the class SwLinePortion and some relevant classes. 2. Keeps the value of external leading in an object instance that holds: * line height (= external leading + ascent + descent) * its ascent (= external leading + ascent) 3. In a method in which the position of base line will be adjusted with the amount of line height and its ascent based on a type of alignment, the value of external leading will be also taken into consideration. Since the patch is created during efforts for the issue 85430 that depends on this issue, the patch includes code fragments for both issues. Although I do try to work for them separately, merging two separated patches that are closely related each other has a risk of conflicts. Please use a shell command like this for your evaluation. build debug=1 'envcflagscxx="-DTORA_PATCH_ADJUSTING_RUBY_LINE_85430 -DTORA_DEBUG -DTORA_PATCH_ALIGNMENT_MIDDLE_85422"' tora->hdu: Thank you for your interests. The value of magic, 0.30, might be needed further discussion in the near future. Many Japanese word processors are capable to have a leading between lines from 0.5, 1, 1.5, 2, and so on. The value 0.5 means half a size of ordinal line height! FYI. The patch does not include any code for vcl, but solely sw.
Created attachment 51150 [details] Patch for both issue 85422 and issue 85430
Reassigned to SBA.
fme->tora: Thank you for your patch. I'll have a look...
tora->fme: Thank you for your consideration. The patch 85422_Alinment_Middle_and_85430_Position_of_Ruby_Text.patch is a little bit obsolete. I have worked on the another issue 85430 and have also refined code fragments for this issue. I am submitting the latest patch next week, which would successfully separate code fragments from another issue 85430.
Created attachment 51456 [details] Patch revison 2008-02-11, which requires i85991-2008-02-11.patch
tora->fme: Here is the latest one. Patch i85422-2008-02-11.patch - tries to solve this issue. - requires i85991-2008-02-11.patch from the issue 85991. - does not include any code fragment for the issue 85430.
fme->tora: I created a cws (fmepatches02) for this issue.
*** Issue 85430 has been marked as a duplicate of this issue. ***
fme->tora: Is your work on this finished? Did you make sure that this does not interfere with pflin's new grid implementation? If so, please make sure to have your patch based on a recent DEV300 version and send this issue back to be, I'll review issue 85991 and issue 85422 together and integrate them.
tora->fme: I have started working on this and related issues with DEV300_m6. The patch file attached in February was based on OOo 2.3.0. A new, up-to-date patch that might cover issue 85991 and issue 85422 would be available soon.
tora->fme: I am submitting a patch to BEA300_m1 in a few days.
tora->fme: Thank you for waiting. A patch has been submitted to the issue 85991.
*** Issue 98209 has been marked as a duplicate of this issue. ***
I'm adding this comment to all open issues with Issue Type == PATCH. We have 220 such issues, many of them quite old. I apologize for that. We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0. If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know. On the other hand, if the patch is no longer relevant, please let us know that as well. If you have any general questions or want to discuss this further, please send a note to our dev mailing list: dev@openoffice.apache.org Thanks! -Rob
Reset assigne to the default "issues@openoffice.apache.org".