Created attachment 142450 [details] sample document 1,open new writer document. 2,Format > page > page 3,Set "Text direction" to "Right to left(vertical)". 4,"OK" 5,Insert new object(Text box,shape,etc..) 6,Set object anker to "page". 7,Inserted object will disapear.(Object still on document,but can't look)
Couldn't reproduce it. But I also couldn't follow your steps, because I couldn't find the setting "text direction" in Format => Page => Page. I can find it in Format => Paragraph => Alignment: Text directon "Right-to-left (RTL)"
Created attachment 142479 [details] format > page > page Screen shot of configure text direction in page format setting.
Created attachment 142491 [details] Screenshot page style dialog There are obviously differences in the UI of the page style dialog between Windows and your System (Linux?). Perhaps someone else is able to reproduce the bug
It is needed to 1. open "Tools" > "Option" > "Language Settings" > "Languages" and 2. check "Asian" and choose e.g. "Japanese" as "Default Languages for Documents" in advance for making the text direction option available in the "Format" > "Page" > "Page" dialog Confirmed the reported behavior with the following vesions: Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group and Version: 6.2.0.0.alpha0+ (x64) Build ID: 7c666e66b7f176bd8910e64f6008ff24151b37a5 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group threaded
Regression introduced by: author Michael Stahl <mstahl@redhat.com> 2016-12-06 21:59:40 (GMT) committer Michael Stahl <mstahl@redhat.com> 2016-12-07 13:46:07 (GMT) commit 689cead9e0837dc932e3a4cd765f7d319b529018 (patch) tree cd6cdcd77f017ef1e60ec11556617da5b1c39721 parent b346439637b7d03a3eb1d6e67dfb585b357567f4 (diff) tdf#91260 svx, sw: don't paint off-page part of drawing object Since commit a4dee94afed9ade6ac50237c8d99a6e49d3bebc1 Writer no longer forces drawing objects to be entirely on one page. However since there is only one SdrPage for the entire document, a drawing object dangleing off the bottom of one page will be painted again on the next page, which is clearly undesirable since Word doesn't do that (and it also destroys the nice invariant that a fly on page N never overlaps a fly on page N+1). Bisected with: bibisect-linux-64-5.4 Adding Cc: to Michael Stahl
*** Bug 119712 has been marked as a duplicate of this bug. ***
@Justin, @Miklos, I thought you could be interested in this issue...
Bug still manifests with: Version: 6.2.0.0.alpha0+ Build ID: ad6adb1bfadf49af3187a0bb3ceffbf355e9eed1 CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-29_02:45:20 Locale: en-US (en_IL); Calc: threaded without any Asian-language-related settings (but with CTL enabled).
(In reply to Eyal Rozenberg from comment #8) I'll also add that in my Page | Page dialog, I see the list box, but vertical directions aren't an option. I reproduced with the attached document.
Still reproduced on 6.2.3 Win & Linux.
Created attachment 151304 [details] screenshot gif Confirmed on master: Version: 6.3.0.0.alpha0+ Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35 Locale: tr-TR (tr_TR.UTF-8); UI-Language: en-US Calc: threaded
Still reproduced on 6.2.4 Win & Linux. *Behavior of each type of object that anchored to the page. -Picture:Visible -Shapes:Not visible -Frame:Visible -Shapes inner of frame(Frame is anchored on page):visible
Still reproduced on 6.3.4 Win & Linux.
Version is supposed to be the earliest affected - which would be 5.4 as per the bibisect.
Still reproduced on 6.4.0.2 in Linux.
Still reproduced on 7.0.0.0 Alpha1 on Linux.
Still reproduced on 7.0.0.0 Beta2 on Linux. Version: 7.0.0.0.beta2 Build ID: 1c213561a365b5666167321de68c9977500c9612 CPU threads: 8; OS:Linux 5.4; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
Reproduced on 7.0.0.1 RC1 on Windows. Version: 7.0.0.1 (x64) Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd CPU threads: 8; OS:Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL
Reproduced on 7.0.2 Linux. Version: 7.0.2.2 Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
Reproduced on 7.2.0.0.beta1 Linux. Version: 7.2.0.0.beta1 / LibreOffice Community Build ID: c6974f7afec4cd5195617ae48c6ef9aacfe85ddd CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
I tried to reproduce with version 7.3.0.3 on Linux, and have a few preliminary questions. 1. Some users here seem to use "Text direction" "Right to left(vertical)". While others use "Text direction" "Right-to-left (RTL)". I am not sure these are the same thing. 2. I tried to insert a text box. But only had 3 options to Anchor by a mouse left click. These were 2.1 To Paragraph 2.2 To Character and 2.3 As Character. I assume that anker from comment #0 is anchor. Is that the case? 3. Must I try with an Asian language ticked in?
I am u34 from comment #21, fixing an error I have made in comment #21: > I tried to reproduce with version 7.3.0.3 on Linux, and have a few > preliminary questions. > 1. Some users here seem to use "Text direction" "Right to left(vertical)". > While others use "Text direction" "Right-to-left (RTL)". I am not sure these > are the same thing. > 2. I tried to insert a text box. But only had 3 options to Anchor by a mouse > left click. That should have been a right, not left, mouse click > These were > 2.1 To Paragraph > 2.2 To Character > and > 2.3 As Character. > I assume that anker from comment #0 is anchor. Is that the case? > 3. Must I try with an Asian language ticked in?
(In reply to u34 from comment #21) > 1. Some users here seem to use "Text direction" "Right to left(vertical)". > While others use "Text direction" "Right-to-left (RTL)". I am not sure these > are the same thing. It's "Right-to-left (vertical", and the it's in the "Text direction" dropdown of the Page Style dialog's (used to be named Page) Page tab. > 2. I tried to insert a text box. But only had 3 options to Anchor by a mouse > right click. These were Good point, this option was removed from the right-click menu. I could bibisect the change to bug 135836's fix. Now you need to right click shape -> Position and Size, and pick the anchor "To page" there. > 3. Must I try with an Asian language ticked in? That's not needed.
(In reply to Aron Budea from comment #23) > (In reply to u34 from comment #21) > > 1. Some users here seem to use "Text direction" "Right to left(vertical)". > > While others use "Text direction" "Right-to-left (RTL)". I am not sure these > > are the same thing. > It's "Right-to-left (vertical", and the it's in the "Text direction" > dropdown of the Page Style dialog's (used to be named Page) Page tab. > > > 2. I tried to insert a text box. But only had 3 options to Anchor by a mouse > > right click. These were > Good point, this option was removed from the right-click menu. I could > bibisect the change to bug 135836's fix. > Now you need to right click shape -> Position and Size, and pick the anchor > "To page" there. > The following is with Tools ->> options… ->> Languages with no Asian languages support, but does have Complex text layout. 1. Right-to-left (horizontal) text direction is selected for the page 1.1. File ->> new ->> Text Document. 1.2. Insert ->> Shape ->> Basic Shapes ->> Rectangle, and dragging the rectangle corner results in a colored rectangle with lines for its edges. I didn’t clicked in the rectangle area with the right mouse button to add text into it because I assumed that is not required for verifying this bug. 1.3. Right click the rectangle, Position and Size..., and pick the anchor "To page" there. Leaving everything else as is. This results in 9 small squares that mark the rectangle edges. Without any lines for its edges. And without the color the original rectangle had. Right click inside the rectangle to see what are the settings for Line... and Area… shows the previous settings are still there. A line for the rectangle edges, and a color for its area. 1.4. Left click the page outside the rectangle makes the rectangle disappear. 1.5. Left click again, this time inside the area where it was shows the small 9 squares that mark its edges. 2. Left-to-right (horizontal) text direction is selected for the page Bug is not present. I wonder if the problem is not rooted to the fact that Left-to-right (horizontal) is not exactly the same as no requirement for direction for the text is. That is, what native European users see as Left-to-right (horizontal) is not exactly as what RTL languages users see as Left-to-right (horizontal). And that what RTL languages users see as Left-to-right (horizontal) is not exactly the same as what Asian languages users see as Left-to-right (horizontal). > > 3. Must I try with an Asian language ticked in? > That's not needed.
(In reply to u34 from comment #24) > (In reply to Aron Budea from comment #23) > > (In reply to u34 from comment #21) > > > 1. Some users here seem to use "Text direction" "Right to left(vertical)". > > > While others use "Text direction" "Right-to-left (RTL)". I am not sure these > > > are the same thing. > > It's "Right-to-left (vertical", and the it's in the "Text direction" > > dropdown of the Page Style dialog's (used to be named Page) Page tab. > > > > > 2. I tried to insert a text box. But only had 3 options to Anchor by a mouse > > > right click. These were > > Good point, this option was removed from the right-click menu. I could > > bibisect the change to bug 135836's fix. > > Now you need to right click shape -> Position and Size, and pick the anchor > > "To page" there. > > > > The following is with Tools ->> options… ->> Languages with no Asian > languages support, but does have Complex text layout. > > 1. Right-to-left (horizontal) text direction is selected for the page > 1.1. File ->> new ->> Text Document. > 1.2. Insert ->> Shape ->> Basic Shapes ->> Rectangle, and dragging the > rectangle corner results in a colored rectangle with lines for its edges. I > didn’t clicked in the rectangle area with the right mouse button to add text > into it because I assumed that is not required for verifying this bug. > 1.3. Right click the rectangle, Position and Size..., and pick the anchor > "To page" there. Leaving everything else as is. This results in 9 small > squares That was not 9 small squares. There were 8 small squares. 8, not 9. And the same goes for the rest of my message. > that mark the rectangle edges. Without any lines for its edges. And > without the color the original rectangle had. Right click inside the > rectangle to see what are the settings for Line... and Area… shows the > previous settings are still there. A line for the rectangle edges, and a > color for its area. > 1.4. Left click the page outside the rectangle makes the rectangle disappear. > 1.5. Left click again, this time inside the area where it was shows the > small 9 squares that mark its edges. > > 2. Left-to-right (horizontal) text direction is selected for the page > Bug is not present. > > I wonder if the problem is not rooted to the fact that Left-to-right > (horizontal) is not exactly the same as no requirement for direction for the > text is. That is, what native European users see as Left-to-right > (horizontal) is not exactly as what RTL languages users see as Left-to-right > (horizontal). And that what RTL languages users see as Left-to-right > (horizontal) is not exactly the same as what Asian languages users see as > Left-to-right (horizontal). > > > > > 3. Must I try with an Asian language ticked in? > > That's not needed.
The error is the same for "right-to-left (vertical)" and "right-to-left (horizontal)". Tested with Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4e2ce2a460458f17ee4360c45a2da2fc4b4d753e CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL
The problem still exists in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1309e6332d7ff2bd1f9b6bf87385b8b570e59158 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
I believe this and 124987 are dupes of each other. If that's not the case - can someone please explain the difference?
(In reply to Dieter from comment #3) > Created attachment 142491 [details] > Screenshot page style dialog > > There are obviously differences in the UI of the page style dialog between > Windows and your System (Linux?). Perhaps someone else is able to reproduce > the bug I do not have Windows. I am not sure the OS is what makes the difference for the issue at hand. I am not sure you are missing the page text direction option because some other options are not set in your installation. With Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 2; OS: Linux 6.9; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US 24.2.5-1 Calc: threaded it could be I must Tools -> Options... -> Languages and Locales -> General -> tick the Complex text layout at the right pane first. For me, the selection of the ticked Complex text layout is set to Default - Hindi.
(In reply to Eyal Rozenberg from comment #28) > I believe this and 124987 are dupes of each other. > > If that's not the case - can someone please explain the difference? +1. There seem to be a difference in the order of operations, at least for the initial reports. At bug #117938, this one, you set RTL before the object is completed. At bug #124987, its is the other way around. As for another difference, #124987 does not assume you enabled complex text layout in the first place. (Which could be what confused Dieter from this bug comment #1 and comment #3). Never the less, these differences do not seem to change the outcome of the operations.
(In reply to u34 from comment #30) Based on that, let's mark a dupe. And I'll choose this one as the dupe, as bug 124987 don't require vertical page layout support. *** This bug has been marked as a duplicate of bug 124987 ***