Issue 85991 - Taking account of leading value in positioning characters
Summary: Taking account of leading value in positioning characters
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: formatting (show other issues)
Version: OOo 2.3
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 85422 85430
  Show dependency tree
 
Reported: 2008-02-11 05:39 UTC by tora3
Modified: 2017-05-20 11:15 UTC (History)
5 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Patch revison 2008-02-11 (18.70 KB, patch)
2008-02-11 05:55 UTC, tora3
no flags Details | Diff
A patch to BEA300_m1, covering i85991, i85430, and i85422. (87.47 KB, patch)
2008-05-06 01:59 UTC, tora3
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description tora3 2008-02-11 05:39:43 UTC
Basic functions for issue 85422, issue 85430 and others.

This patch tries to 
 - add a method GetLeading() besides GetAscent() and GetHeight()
 - keep a leading value in a class SwLinePortion for later use
Comment 1 tora3 2008-02-11 05:55:55 UTC
Created attachment 51455 [details]
Patch revison 2008-02-11
Comment 2 frank.meies 2008-02-11 07:50:52 UTC
fme->tora: Thank you for your patch! I suggest to change the existing
GetDefaultAscentAndHeight() function instead of introducing a second one. Please
have a look.
Comment 3 michael.ruess 2008-02-11 08:28:35 UTC
Reassigning this Patch proposal to FME.
Comment 4 tora3 2008-02-11 08:32:43 UTC
tora->fme: That makes sense. I will follow you.
Comment 5 frank.meies 2008-02-13 16:35:54 UTC
Set target to 3.x.
Comment 6 frank.meies 2008-03-01 08:05:57 UTC
fme->tora: I created a cws (fmepatches02) for this issue.
Comment 7 tora3 2008-03-03 12:25:53 UTC
tora->fme: Great! Thanks a lot.

I am submitting the latest patch of this issue in a week. 
The patch will be a part of efforts from the project [2]. 

Source codes of Release 2008-02-29 [1] have a problem with layout of ruby text. 
A ruby text portion is unexpectedly chopped by the neighbor line. 
The bug came when I introduced an idea of RealRubyHeight to attempt of solving 
another problem that the first text portion of a line is wrongly positioned. 

[1] http://wiki.services.openoffice.org/wiki/Jsdp2007
[2] http://wiki.services.openoffice.org/wiki/Grid_%28lines_and_spacing%29

Ciao, Tora
Comment 8 frank.meies 2008-04-02 08:28:55 UTC
fme->tora: Any new on this? Is this still bing worked on or is the patch "ready
for review"? In this case I will review the patches for issue 85991 and issue
85422 and add them to a cws.
Comment 9 frank.meies 2008-04-08 09:42:39 UTC
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.
Comment 10 tora3 2008-04-08 10:44:48 UTC
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. 
Comment 11 tora3 2008-05-06 01:59:23 UTC
Created attachment 53399 [details]
A patch to BEA300_m1, covering i85991, i85430, and i85422.
Comment 12 frank.meies 2008-05-23 09:14:45 UTC
fme->tora: Thank you for your patch. This is really quite a lot of code changes
;-) I had a first look at your patch and like to give you some feedback. First,
I have set up a cws ('rubyadjust') and committed your patch to that cws. Please
make any further patches basing on this cws, this way it is much easier for us
to have your work in sync with the current milestones. So here are my comments:

1. Shouldn't we initialize the ruby height values in the constructor instead of
WhichTxtPor()?
2. I see that in ::PaintMultiPortion the meaning of bHasGrid has changed. Is
this intended?
3. I'd like to make sure that the overall layout of the document has to remain
stable for existing documents. If the position of the glyphs inside a line
change, that's acceptable. But we should avoid changing e.g., line heights. I
think the code in ::CalcRealHeight might change the layout of existing
documents, is this correct? In this case I suggest to implement a new (hidden)
compatibility flag (see doc.hxx) that makes sure that any layout related code
changes do not affect old documents.
4. Please add some more comments to the changed code, this way it is much easier
for me to review your changes.
5. Some of the new members nRubyHeight* in SwLinePortion are only set for ruby
multi portions I guess. In this case I suggest to move the values to the multi
portion.
Comment 13 tora3 2008-05-23 13:38:31 UTC
tora->fme: Thank you for your consideration and invaluable comments. 
I will try to do that one by one. 
Comment 14 Rob Weir 2013-03-11 15:01:05 UTC
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
Comment 15 Marcus 2017-05-20 11:15:54 UTC
Reset assigne to the default "issues@openoffice.apache.org".