Apache OpenOffice (AOO) Bugzilla – Issue 76247
Text grid enhancement for better CJK support
Last modified: 2013-08-07 14:43:03 UTC
Grid layout is mainly used for CJK environment. But it's behavior is somewhat different from the real expectation of CJK users. The problem is, when we change the “Lines per page†setting in “Text Grid†Tab Page, the type area of the page will also change, which is not fitting the user habit of CJK users. In OpenOffice, the “Characters per line†setting has the most high priority, it will determine the height of line, then the “Lines per page†setting has the second priority, it will determine the height of type area. This kind of design is used to simulate “squared paperâ€, which is a kind of specific paper used 20 years ago(before personal computer is widely used in text processing). But now, “squared paper†is only used in very limited case, and most CJK users won't use it anymore. Now the common usage is: type area has the most high priority, it will determine the height of line; the “Lines per page†setting has the second priority, and “Characters per line†setting can only determine the width of characters, and can't influence line height in anyway. Please see the feature specification for more details.
Created attachment 44331 [details] Feature specication of text grid enhancment
Reassigned to SBA.
In the specificaion, I think maybe in the grid lines only option, the user still should be able to change the number of characters per line, I don't think the user want to ignore the option to change the characters per line, disable the option is killing flexibility. what do you think?
As mensioned in the ODF spec ( section 15.2.21) , when the grid type is line only, the page is divided in a fixed number of lines. So the user just concerns lines per page, and it is no sense to change characters per line. If characters per line is also enabled, the behavior will be same as "line and characters". I think it is not accurate.
Added myself as CC
From a western user's point of view, it would be welcome to hide the new controls from the UI, unless "Enabled for Asian languages" is set in the Language Options.
Good suggestion. This function will be added.
Hi all, unfortunately Redflag CH2000 has been working on this feature too and was preparing to submit an own specification by the beginning of May. We studied Novell's specification and we think that our approach is richer in features. We will speed up to prepare proposal and post this alternative spec by the middle of May Hopefully, both implementations do not differ too much and it will be possible to cooperate and this feature.
That is great. We can cooperate to enrich OO.org and make OO.org better support CJK users.
Hi: We will put the specification as soon as possible, hope can make it by the end of April. thx
The codes have been merged into the cws cjksp1 based on SRC680_m208. and waiting for review and verify.
pflin->fme: Please review CWS cjksp1
fme: I'll have a look.
fme->pflin: Looks like you forgot to commit optload.hxx.
pflin->fme: optload.hxx was just committed. sorry for inconvenience
fme->pflin: I had a first look at your cws and want to share my findings with you. First I found that the behavior of the old tab page changed. The number of lines settable used to be restricted based on the base line height. This has changed. A second issue is that you should resync your cws to m210 or newer, see Vladimir's posting on dev@openoffice.org 'IMPORTANT ANNOUNCEMENT: HEDABU DOESN'T EXIST ANYMORE'. A third thing to remark is that I encountered a couple of very serious assertions coming from svtools (itempool.cxx ...) during putting of the SwTextGridItem. I strongly suggest to test your cws again with a non-product build (see ./configure --help, I guess the name of the switch is something like --enable-dbgutils).
pflin-->fme: Thanks for your comments. I will check the issues your mensioned and resync the cws to the newer soon.
pflin-->fme: The following is done per your comments. Please review it again. * resync to m211 * recover the behavior of old tab page * remove the assertions in non-product build and fix some bugs Thanks!
fme->pflin: Some more remarks: 1) Open a new document (while having the configuration set to 'use square mode'). Do not enable grid layout. Switch configuration setting (Tools - Options ...) to 'non-square mode'. The page margins change. 2) In SwDoc::SetDefaultPageMode I would suggest to use some code like this: for ( USHORT i = 0; i < GetPageDescCnt(); ++i ) { SwPageDesc& rDesc = _GetPageDesc( i ); SwFrmFmt& rMaster = rDesc.GetMaster(); SwFrmFmt& rLeft = rDesc.GetLeft(); SwTextGridItem aGrid( (SwTextGridItem&)rMaster.GetAttr(RES_TEXTGRID) ); aGrid.SwitchPaperMode( bSquaredPageMode ); rMaster.SetAttr( aGrid ); rLeft.SetAttr( aGrid ); } 3) Currently in officecfg the default is set to 'square mode' whereas the bSquareMode bool of the TextGridItem is initialized to 'false'. This should be consistent. 4) Toggling the stylist (F11) results in a debug output complaining about a missing resource
pflin --> fme. Thanks for your comments. Please review again. (1) Fixed. (2) Accept the codes you suggested. (3) Fixed: The default value of "bSquaremode" is "true" for officecfg and SwTextGridItem. (4) This is not caused by Text grid. Without my codes, the complaining exists too.
fme->pflin: 1. mmp will have a look at the ui changes. 2. you are right, the resource id issue occurs also in a 'plain' m211 3. there's one more issue I found: Switching from non-square mode to square mode does not adjust the default settings for the grid: Open new document - default number of lines in grid tab page is set to 20 (don't enable the grid!) - disable square mode - default number of lines in grid tab page is set to 46 - enable square mode again - default number of lines in grid tab page is 44.
pflin --> fme Fix the bug you found. The default number of line in grid tab page is 20 in square mode. while in non-square mode, the number of line is dependent on the base text size which default value is 15.6pt.
fme->mmp: Please review pflin's UI changes.
I'll have a look; set target to 2.x
related issue: 72655
Matthias, any news?
As the "UX timeout" is exceeded by far I don't want to wait any longer. Frank, please decide on open UI questions on your own (perhaps of course in agreement with pflin).
Ok.
fme->pflin: I'll take over again. I'm sorry that you had to wait that long. From my point of view there are still some issues remaining: 1. According to the OASIS specification, the string has to be named layout-grid-standard-mode, not layout-grid-square-mode, please check this. 2. I think we should not write style:default-page-layout in case that the grid mode is set to standard. This way we avoid ODF 1.1 validation errors if the new feature is not used. Please find a patch attached to this issue for this. 3. According to the specification, layout-grid-standard-mode should be ignored if it is located inside a <style:page-layout> attribute. Therefore I think we should not write layout-grid-standard-mode inside the <style:page-layout> attribute as your code currently does. 4. Writer has been made warning-free since SRC680m231. Please resync to a newer milestone and check if there are any compiler warnings. 5. I still opt for having the grid mode checkbox in the Asian settings dialog, even if this is a Writer only setting. This is definitely the best place for any Asian specific settings. 6. When opening the text grid page for the first time, I always get an assertion, that standard.soc could not be loaded correctly. Looks like the 'office' namespace could not be found by GetKeyByAttrName in xmloff. Do you observe the same?
Created attachment 49070 [details] patch
pflin -> fme: Thank you very much for your comments. 1. I proposed to use layout-grid-square-mode instead of layout-grid-standard-mode when the text-grid proposal was approved. It was not accepted for my mistake (I was new to ODF TC, and was not familiar with the process of ODF TC). In this case, I will change the string into layout-grid-standard-mode. 2. Accept, good solution. I will merge the patch into the cws soon. 3. Accept, good suggestion. 4. I will resync it into SRC680m234. 5. I still opt for having the grid mode checkbox in the Asian settings dialog, even if this is a Writer only setting. This is definitely the best place for any Asian specific settings. 5. Not accept. Since the grid mode checkbox is a Writer only setting, I think it is better in Writer setting dialog. Moreover, this checkbox is shown only if the "Asian language" is enabled. 6. I check a non-product build in SRC680m234 and there is no assertion that you mentioned.
fme->pflin: Two more remarks: 1. I discussed this UI issue with some colleagues and we think we can keep it the way you implemented it. 2. I think nSpaceAdd in fntcache.cxx line 1199 has to be divided by SPACING_PRECISION_FACTOR
fme->pflin: [...] I check a non-product build in SRC680m234 and there is no assertion that you mentioned.[...] Yes, you are right. I forgot to build svx since xmloff had some incompatible changes.
fme->pflin: Any news?
pflin-> fme, Meet some issues when importing the document if removing layout-grid-standard-mode from the <style:page-layout>, fixing now ...
pflin->fme, updated, please review, thanks a lot!
fme->pflin: The wntmsci10 build breaks in various files: docdesc.cxx, itrtxt.cxx, fntcache.cxx, ww8par6.cxx ... Please have a look.
pflin->fme, I check it again, it is ok in my build. please send me the build break log to pflin@novell.com. Thanks.
fme->pflin: Some more remarks: 1) layout-grid-base-width and layout-grid-snap-to-characters are written even if only an 'old' grid is used. 2) Please adjust the specification according to the correct file format strings.
pflin->fme: updated. a stupid method to not write layout-grid-base-width and layout-grid-snap-to-characters if only an 'old' grid is used. Please have a look.
Created attachment 49610 [details] Update the feature specification
fme->pflin: Ok, layout-grid-base-width and layout-grid-snap... are not written anymore in case the feature is not activated. But I found an other problem: 1. Open Writer, disable square mode 2. close office and restart 3. Enable grid 4. save document and close 5. reload that document 6. enable square mode and save Result: The document contains <style:default-page-layout> <style:page-layout-properties style:writing-mode="lr-tb"/> </style:default-page-layout>
fme->pflin: Any progress on this?
pflin->fme, update the file xmloff/source/style/XMLPageExport.cxx for fixing this issue. please have a look. Thanks!
fme->pflin: Looks good. Please check file pagefrm.hxx line 507/508, there seems to be a wrong line end character, which causes the windows build to break. Also ww8par6.cxx does not compile due to line 476.
pflin -> fme, Fix the build break on Win32. Please have a look. Thanks BTW, Is the target milestone 2.4? I hope it would get into 2.4. Thanks.
fme->pflin: [...] Fix the build break on Win32. Please have a look. [...] Done. Works fine. [...] BTW, Is the target milestone 2.4? I hope it would get into 2.4. Thanks. [...] no, the target milestone is 3.0 since the deadline for OOo 2.4 has been missed: http://wiki.services.openoffice.org/wiki/OOoRelease24
My mistake not notice the deadline for OOo 2.4. Regret for missing this milestone.
SBA: Unfortunately, the Feature/UI freeze deadline was not met. Since this feature introduces a new check box (in Tools-Options-Writer-General), its string would miss the translation cycle of OOo 2.4 wich is already under way. Therefore we must retarget the issue and the CWS to OOo 3.0. In my opinion, it does not need to be resynced because the source tree split will come soon. -> Change target milestone. Added Zhu Lihua on CC list.
Hi, Could anyone please tell me where I can get a build of this CWS, so that I can verify it?
Perhaps http://download.go-oo.org/fong/OOo_2.4.0_080222_LinuxIntel_install.tar.gz is a good place to get an install set. According to Pei Feng Lin it is built for Suse Linux 10 sp1, don't know what that means for other penguin species.
Fong, can you try building with the build-bot (cf. http://wiki.services.openoffice.org/wiki/Buildbot) - you have to guess which of the Linux machines is setup to build a 'standard' build (ie. one that Hamburg QA can run) - they are usually not called things like "debian, ARM, experimental" or whatever ;-) There should be an up-load install-set button somewhere too that can do this automatically for you.
-->Michael, thanks, I will have a try soon.
pflin -> lihua, you can get the linux install set from http://buildbot.go-oo.org/install_sets/O3-build-1982-cjksp1-install_set.zip.
Hi, Fong, Downloading, thanks...
tora->pflin: I would like to propose merging the efforts done by your side and the ones by a Japanese project. Here is an experimental implementation and its documentations: http://wiki.services.openoffice.org/wiki/Jsdp2007 http://wiki.services.openoffice.org/wiki/Grid_%28lines_and_spacing%29 http://wiki.services.openoffice.org/wiki/Grid_display_line http://wiki.services.openoffice.org/wiki/Wrong_position_of_ruby_text http://wiki.services.openoffice.org/wiki/Relations_among_lines_and_characters Linux English installation set is available at Jsdp2007 listed above. caio, tora
Hi, Fong, The function we need is working. But I'm sorry to say there is one thing I didn't expect. The style of the grid are changed. The original style is used more commonly than this style. So I think can we use the original style? That is to say, we don't change the grid. only implement the following feature: The type area has the highest priority, it always full filled with grids, together with the "lines per page", so the LineHeight is determined. if we adjust "Characters per line", this will change the width of the character, at the same time, the height of the character will change, but the line height won't change. so the gap line between the lines will change. This is the common expectation of Chinese people which implemented by another commonly used office product, Kingsoft WPS office. Do it this way, then we needn't disable the "Character per line" any more, if we choose "Grid(only lines)". Personally, I always feel the grid in MS Word is no use and ugly. So I don't want OpenOffice degenerate. WPS office do well at this point.
tora->redflagzhulihua: Sorry for interruption. Japanese attempt of enhancing grid layout does exactly what you want, i think. If you adjust "Character per line (1)," "Max. base text size (2)" will be automatically modified and "Max. Ruby text size (3)" will be simultaneously adjusted. However, the sum of (1) and (2) will be kept. (The sum equals line height.) Therefore, "Lines per page (4)" will not be changed. But if you try to set (1) to too small or too big value, such as 1 or 200, (2), (3), and (4) will be modified to keep good balance. That is the specification that Japanese one implements. The implementation works with all grid types: Grid (lines only), Grid (lines and characters), and Grid (lines and character spacing). http://wiki.services.openoffice.org/wiki/Relations_among_lines_and_characters Is that the one you expect?
Oops, there are two typos in the prior post. Here is correction: If you adjust "Character per line (1)," "Max. base text size (2)" will be automatically modified and "Max. Ruby text size (3)" will be simultaneously adjusted. However, the sum of (2) and (3) will be kept. (The sum equals line height.) ^^^^^^^^^^^ Therefore, "Lines per page (4)" will not be changed.
Verified in CWS cjksp1.
Hi, tora, Yes, sounds same as what I think. Perhaps a little difference about this sentence: But if you try to set (1) to too small or too big value, such as 1 or 200, (2), (3), and (4) will be modified to keep good balance. I think adjust (1) shouldn't modify (4), (1) should restrict to a proper range according to (4), so (1) will not be too big or too small. What pflin has done is restricting the min. value of (1). I had thought this effort would keep the original grid lines.
pflin -> lihua, As mentioned in function spec: 1. The original behavior is not changed when the original grid type ( "use squared page mode for text grid" in "tools -> options -> Openoffice.org Writer -> General" tab page) is selected. If there are something need to do for the original behavior, it is better to create new issues for them. 2. If "standard page mode" is used, ( "use squared page mode for text grid" is unchecked), the behavior of "line per page" or "character per line" is similar to MS Word. For this kind of behavior is widely for CJK users( not only Chinese, but also Japanese and Korean ) This new behavior has been discussed in ODF TC and approved in ODF 1.2.
pflin -> lihua, Thank you very much for your test. pflin -> tora, lihua I think both of you are talking about the original grid type which is keep when "use squared page mode for text grid" is checked. For the new grid type which is similar to MS Word 2003, Ruby text is not used.
Hi, Fong, I have no objection to verify this issue, it accord to the specification. I just didn't know the grid line will change to the MS word style. So it abit unexpected to me.
tora->lihua: You have a point. I can partially agree with you. It might be somewhat controversial. The point could be - How to get rid of situation where typical users get confused or frustrated. How to answer to user's inquiry: "I just wanted to increase characters per line. Why did the Writer reject my order to increasing the value. Please clearly explain the reason in short." "I just wanted to increase characters per line. Why did not the Writer prevent from changing lines per page. Please clearly explain the reason in short." There could be a good point to make a balance. Machines including software should obey commands ordered by human. Meanwhile, machines are expected to reject commands if there is possibility to harm humans. tora->pflin: By the way, specs around "Character per line" and "Lines per page" could be discussed separately from this issue. This issue could sorely focus on type of grid. Another issue regarding the number of characters and lines could be filed or an old issue 53425 could be reused. There might be no need to connect the number of characters and lines to type of grid.
Hi Fong, IMHO, introducing the following new items might make users confused. - "use squared page mode for text grid" - "style:snap-to-layout-grid" According to the specs "Text Grid Enhancement for better CJK support V2.4.odt," the squared page mode will be applied for whole text document. That breaks Writer's normal behavior, i think. Writer is capable of managing different page styles. User can put various page styles in a single text document. E.g. The first page would be the cover page without any grid; the second page might be in Writer's original grid type Grid (lines only); and middle pages of the document could be Word-like new grid layout. Therefore, an attribute for the whole document does not meet Writer's page style control mechanism. In addition, according to the specs, "style:snap-to-layout-grid" will be set to false of true depending on what type of file is loaded. When Writer loads a Word file, the value will be set to true. Otherwise, it will be set to false. Is there any way for a user to confirm or change the value? Maybe no. That means Writer will not be capable of preparing a document in Word-like grid layout from scratch. That is not expected. Finally, it is even difficult for me to understand the specs. To determine what type of grid layout engine, Writer would see - whether activated or not of "use squared page mode for text grid" - true of not of "style:snap-to-layout-grid" - whether Grid (lines and characters) is chosen or not That is too complicated for me and that might be difficult for users to understand or utilize. Why don't we simply add the same grid layout algorithm of Word without introducing any new items as Japanese project has achieved? Word's "Specify line and character grid" is capable of managing how many characters will be laid in a single line by controlling a distance between each character. That type obviously turns snap-to-grid disabled as the specs addresses to. In addition to controlling snap-to-grid, the grid type manages distance between characters. That is easy to be incorporated to Writer using Writer's kerning function.
I am sorry. there were typos again. Correction: In addition, according to the specs, "style:snap-to-layout-grid" will be set to false of true depending on what type of file is loaded. When Writer loads a Word file, the value will be set to false. Otherwise, ^^^^^ it will be set to true. ^^^^
I thank all of you about this problem. I used 3.0 beta. There is the point that I want to ask for improvement. When a special character and an alphabet continue, I have big interval. Please watch a snapshot when I read a file of Word with 3.0. I wish this Issue is opened again.
作æˆã•ã‚ŒãŸæ·»ä»˜ (id=53940) snapshot with 3.0
作æˆã•ã‚ŒãŸæ·»ä»˜ (id=53941) sample Word file
pflin->kamataki, thank you for your found. I find that the space between CJK character and western character sometimes doesn't accurate as MS Word expect. This is an issue existing in OOo 2.x which doesn't include the text grid patches. Please file another issue and may assign it to me. I will have a look.
kamataki->pflin: thank you. According to your advice, I registered Issue. http://www.openoffice.org/issues/show_bug.cgi?id=90040
This issue is closed automatically and wasn't rechecked in a current version of OOo. The fixed issue should be integrated in OOo since more than half a year. If you think this issue isn't fixed in a current version (OOo 3.1), please reopen it and change the field 'Target Milestone' accordingly. If you want to download a current version of OOo => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues