Description: UI: Discourage usage of the to page anchor by heading it from toolbar/context menu The to page anchor is a problematic feature: https://ask.libreoffice.org/en/question/199971/multiple-captioned-images/#post-id-199989 It's use should be discouraged. Steps to Reproduce: 1. Open Writer 2. Insert an image 3. Right click the image -> Anchor Actual Results: To page shows up Expected Results: Make the anchor to page only accessible from Image Properties dialog and hide it in other places. Discouraging usage. It's also not compatible with DOCX/DOC so gets converted to different anchor pretty often Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
This would also be helpful to limit the bugs potential bug 135711 bug 135838 So a way of phase out 'to page anchoring' and 'drop' maintaining. At some point even converting 'to page' to different solutions.. The 'conversion code' is already present for DOCX/DOC. But needs a time path and developer opinion and depending on the feedback - angry mob complains - from the user base if they are missing 'to page anchoring' in context menu/ toolbars etc..
This is bad on so many facets. Anchor to page is critical for doing large frame and section document layouts. Think posters and artboards. Otherwise, the ODF handling is pretty correct. Issues of export round-trip import conversions as MS binary or OOXML formats are legitimate filter issues. But do not merit elimination/supression of a substantial LO capability in working with ODF archive documents.
(In reply to V Stuart Foote from comment #2) > This is bad on so many facets. Anchor to page is critical for doing large > frame and section document layouts. Think posters and artboards. > > Otherwise, the ODF handling is pretty correct. Issues of export round-trip > import conversions as MS binary or OOXML formats are legitimate filter > issues. But do not merit elimination/supression of a substantial LO > capability in working with ODF archive documents. It;s more or less based on ask posting. "I strongly advocate against this type of anchoring." FWIW, there is also bug 135835. Where I'm advocating for name change. There are more or less two different directions/proposals :-). I surely don't know they legit user cases. However I assume quite a number of benjamins are abusing/misusing 'to page' anchoring. And in addition you get comp-ability issue with different formats. Removal maybe excessive, but suppression might be helpful. We are talking about what's desired for largest group of users, IMHO The context menu can be customized and the 'to page' re-added if people desire it. This more about what should be the default. And it's not so that the option is gone; it's still in image properties; so it can be seen. I'm surely unaware of the group using to page anchoring for legit reason "for doing large frame and section document layouts." etc. However not sure if it should be advisable to design posters with Writer, but that's more a hunch. This is actually similar to the discussion about 'mark-down feature' or 'tabbed' mode. What's desired for group A is problematic for group B, and less optimal for C. Hiding special features, make them unknown. Make special feature more prominent and other people get confused of frustrated. As Markdown has undesired results depending what you're doing(and I'm still bit of geeky feature used by certain group/professions). Similar to LaTeX is being promoted some area's. The one size fits all will always be complicated. At some point the we end up with modes: 'regular user' (tabbed, basic), "power-user" (toolbar + ??), graphic designer (special toolbar setup). If this is done by an installation wizard/ extension or whatever. Or list of setting with a preset depending on type of user There quite of group of people annoying by the autosuggest (without known it can be turned off). Or as said the mark-down feature (which surely must make some people crazy). Or people being unaware of special replacement lists. Or even extensions like LanguageTool for that matter (not knowing much about must used extensions actually).
There is no point in discouraging the use neither renaming the function. It is just one of the features that require to learn the usage. To Page is known as that in all major text processors, so dropping it would be a serious regression. And ultimately it's also a bit nitpicking to me. Even when it's unclear how exactly this works you may try and see what goes on. Everything beyond needs to be addressed in the help (CC'ing Olivier).
(In reply to Heiko Tietze from comment #4) > Even when it's unclear how exactly this works you may try and see what goes on. This started with me reporting bug 135829. I was pointed to Quote from: https://ask.libreoffice.org/en/question/199971/multiple-captioned-images/#post-id-199989 * "To Page is very special, and actually is very unfortunate to even exist."* While the first four mean that an object is linked to some real fundamental document elements - paragraphs, characters, or frames, that actually constitute the document, - the To Page anchoring links objects with something ephemeral, dynamic in the world of text processing software, to something created and destroyed on demand: to a page number. Any given page is only existing there because there's some text that needs to be placed on a page. As soon as the text gets modified/reformatted, it might take less paper space than before, and any given page may become unnecessary. Or the text may grow, edits may insert content before any given text, and so any paragraph may move to following pages. But objects linked to "page number" would stay where they were, would not move anywhere; would cause blank pages to be kept - just to let the linked object stay there. There's nothing in the document that would let these objects move forward or backward - if you insert more pages "before" such objects, the objects would "jump" to "previous" pages, actually keeping anchored to the same "page number 3 in the document, no matter what"." *"I strongly advocate against this type of anchoring."* Not saying the author/ developer did say to hide or remove it; that's based on my reading of it. And my experience with this type of anchor -> Bug 135829 -> Bug 136581 -> Bug 135838 -> The beloved attachment 164912 [details] effect (plenty of empty pages). Which always a 'odd' experience -> The can't be exported to DOCX/DOC (so gets converted) The fact that To page can be understood differently (Bug 135829). To this page, instead to this page at exactly this position (within a range of pages). So what I tend to say: To Page isn't self-explaining feature. Also I have seen number of documents where they to page anchor is used, where you can ask question why this being done. Not for they 'stick to this page, and exactly this page' aspect, IMHO. So or people are 'abusing' To Page for something different compared to what was expected for. In that case I should be replaced by To Page anchoring 2.0. So I would love 'some arguments' why this should be accessible at prominent place. It's certainly not obvious where 'to page' stands for. Nor do I actually know if all major text editors support this (it doesn't seem Word doing this); else the DOCX export broken.... I listed a number of 'issues'. Why I prefer 'reducing' they prominence. Which indirectly 'discourage' they use. If it only be in the 'right click' context menu. I would love a list of where this is being useful; making sense (for ideally the largest group). Still not clear that benefits of the 'to page' anchoring are. And especially where the advantage is for they 'general public'; which I assume is the main audience. Is there actually an UX analyses of they user base. And guidelines say visibility of features ? And what they need. They read the lovely manual/help still not really convincing. My principle is keep it simple; idiot proof; with advanced features slightly buried. Or a quick configure dialog to 'tweak' you're LibreOffice as desired (with only 'basic' functionality at the start) There is no UX-reach department with telemetry, UX interviews, observations of X number of users.. This will be again a topic where we are battling blind folded? I'm aware that most people around here are more experienced with 'changes' (and the backfiring). They change isn't major. Nor definitive.. In the sense that can be customized back into they context menu. It's still accessible from other dialogs. And it's even possible by experiment in Master and see how many complains we get at beta/rc. Not an invitation to arrange an angry mob. Drifting off: I assume power users to tweak LibreOffice to their desires.. Not set the power user features to default so they main audience can struggle with it. As they didn't ask for it/ require it (or shouldn't use it). There are certainly 'default' where I question if this being direct to main public, or more based on personal preferences groups with special needs/ and desires. Markdown partial or full is a feature you enable, IMHO. Not being enabled by default (similar as autocomplete). Except if LibreOffice being advertised as a Markdown or even LaTeX editor in principle. If have the bright idea of 'we can do this too'; it's a feature which do enable. As long as you don't intend to be a markdown editor all the way. However, I assume my opinion to by pretty clear already ;-)
(In reply to Telesto from comment #5) > This started with me reporting bug 135829. I was pointed to... You convinced me and I support your suggestion now: (In reply to Telesto from comment #0) > Make the anchor to page only accessible from Image Properties dialog and > hide it in other places. Discouraging usage. Code pointer: .uno:SetAnchorToPage /core/sw/uiconfig/swriter/popupmenu/anchor.xml Maybe also in /core/sw/uiconfig/swform/popupmenu/anchor.xml /core/sw/uiconfig/swreport/popupmenu/anchor.xml /core/sw/uiconfig/swxform/popupmenu/anchor.xml Don't think we need to change these menus /core/sw/uiconfig/sweb/popupmenu/ /core/sc/uiconfig/scalc/popupmenu/ /core/sw/uiconfig/sglobal/popupmenu/
(In reply to Heiko Tietze from comment #6) > (In reply to Telesto from comment #0) > > Make the anchor to page only accessible from Image Properties dialog and > > hide it in other places. Discouraging usage. > /swriter/popupmenu/anchor.xml > /swform/popupmenu/anchor.xml > /swreport/popupmenu/anchor.xml > /swxform/popupmenu/anchor.xml If that was the intention, then this patch "removes" the "To page" option for images and shapes in the just-named context menus. https://gerrit.libreoffice.org/c/core/+/103648 >(In reply to Telesto from comment #3) > The context menu can be customized and the 'to page' re-added if people > desire it. Not with this patch. As best I can tell, cannot "hide" this option so that it can be customized back. Furthermore, if the objective is "only accessible from Image Properties dialog" then what about "Shapes", which will also lose the "To Page" in its context menu? For Shapes, one would then need to use "Position and Size" (to set "to page" anchor) (because no Properties dialog). (not objecting, just informing, in case it has consequences.)
(In reply to Heiko Tietze from comment #4) > It is just one of the features that require to learn the usage. > Even when it's unclear how exactly this works you may try and see what goes on. > Everything beyond needs to be addressed in the help (CC'ing Olivier). Here is the existing LO help I can find about "To Page" in Writer's Guide 6.0 To Page The graphic keeps the same position in relation to the page margins. It does not move as you add or delete text or other images. This method is useful when the graphic does not need to be visually associated with a particular piece of text. It is often used when producing newsletters or other documents that are very layout intensive, or for placing logos in letterheads. (plus a warning about not using "to page" with master documents) And online help: https://help.libreoffice.org/7.1/en-US/text/swriter/guide/anchor_object.html If more help (or warning) information would be appropriate/useful, then concrete suggestions for what to add are welcome, possibly as separate bug report.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/09c24681a3414092fde50ec0f617c9f7c79e8a61 tdf#135836 remove "to page" from shape/image contextmenu It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 7.1.0.0.alpha0+ Build ID: 6923b1d527fa86fac8439b881d4ad468b765e915 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Please revert it! It was a mistake
Please revert this change! The logic and rational for requesting this change was ill conceived.
(In reply to Roman Kuznetsov from comment #11) > Please revert it! It was a mistake Hi Roman, Dave, What do to want to revert? and why ?
(In reply to Xisco Faulí from comment #13) > What do to want to revert? and why ? See bug 140702
After so much tim:e it was ill decision useful maybe for bug reporters and discussion, but harmful for users who used it.
1. This is still in the online help: https://help.libreoffice.org/25.2/en-US/text/shared/01/05260100.html?DbPAR=SHARED#bm_id271692908662893 2. So, how do I anchor to page in Draw or Impress?
(In reply to Eyal Rozenberg from comment #16) > 1. This is still in the online help: > > https://help.libreoffice.org/25.2/en-US/text/shared/01/05260100. > html?DbPAR=SHARED#bm_id271692908662893 > Please write a new bug report for that. The current way to set the anchor type to "page" is the "Position and Size" dialog. > 2. So, how do I anchor to page in Draw or Impress? Draw and Impress have no anchor type at all.