Make frames rotatable. Text Box can be rotated but cannot receive database fields. Frames can receive database fields but cannot be rotated. When printing tent cards for conference guests or dinner guests, a database can be used to source the information to be printed. However, only the front of the card can be printed on. I have to print labels for the backside. Being able to rotate a frame means I can print on both sides in a single print job.
Reading Regina's bug 91530 comment 9 it seems possible. But OTOH Luke's c12 in the same bug states that rotation cannot applies to frames. Now I wonder if rotation is possible with ODF. Rotating an image means to enlarge the surrounding frame to the size of the diagonals of the content. Doing the same for text with all formatting could be difficult. To support the request: Since we want to foster the use of (interactive) frames over text boxes (see bug 139606) the missing rotation might be a regression for some users.
(In reply to Heiko Tietze from comment #1) > Now I wonder > if rotation is possible with ODF. > The difference between 'Frame and writer-image' and 'textbox and draw-image' does not exist in ODF. So yes, rotating a frame or a write-image can be written without problems in ODF. Only LibreOffice is not able to render it.
See bug 91530 comment 12. The closer we follow this: http://www.addbalance.com/word/frames_textboxes.htm This less interoperability issues our users will have. If modify the frame behavior, we should add the flag that triggers the "This document may contain formatting or content that cannot be saved in the currently selected file format "Word 2007-365"." message at export time. Miklos, Rather than change frames, I think a better solution would be to allow the fields that OOXML support in our textbox implementation. Do you see a problem with this?
(In reply to Luke from comment #3) > Rather than change frames... We should not limit ourselves because of missing capabilities at competitors. Please consider bug 139606 - frames have advantages over text boxes.
(In reply to Heiko Tietze from comment #4) > We should not limit ourselves because of missing capabilities at > competitors. There is an old well defined concept of a frame that MSO, WP, and LO have similar functionality and a new concept of a textbox. Carl’s problem can be fixed by either 1) upgrading our textbox to match MSO’s or 2) breaking that long established compatibly. Choosing 1) over 2) hurts compatibly and users that depend on it. Why should that fact not be taken into consideration? I work in IT and every chance I get, I advocate for migrating to MSO in my shop. But poor interoperability is the reason why we have not migrated. MSO is the most used Office Suite. By dismissing the consideration of compatibly in the choice of 1) or 2), you are hurting the UX of the vast majority of our users. The only chance LO has of ever gaining marking share is to focus on compatibly.
(In reply to Luke from comment #5) > There is an old well defined concept of a frame that MSO, WP, and LO have > similar functionality and a new concept of a textbox. Carl’s problem can be > fixed by either 1) upgrading our textbox to match MSO’s or 2) breaking that > long established compatibly. Choosing 1) over 2) hurts compatibly and users > that depend on it. Why should that fact not be taken into consideration? Good arguments. So you would resolve the request as WONTFIX since MSO lacks on the feature? Maybe we do not allow frame rotation (once implemented) until a compatibility flag is checked.
Do we stop the development of all new features until our competitors have implemented them first? Are we followers or leaders? Perhaps that's unfair. IMHA I think that we should introduce this and flag it as an incompatibility etc. MSO for example, wouldn't wait. They would simply steam ahead and flag it a "Minor Loss of Fidelity".
(In reply to Heiko Tietze from comment #6) > Good arguments. So you would resolve the request as WONTFIX since MSO lacks > on the feature? No. There is a valid issue here. But the solution should be to enhance Textboxes to support fields.
I disagree with Luke in C8. Enhancing frames to allow rotation should be the way to go. It yields a far better user experience and yields greater perceived functionality. Look at it this way: adding fields to textboxes does just that. However, adding rotation to frames yields a textbox replacement that now has hoops of functionality otherwise lacking in textboxes. I've yet to be convinced as to why the two elements exist. As I see it, adding rotation to frames is the answer. When it comes to compatibility, converting to ODF: convert inbound textboxes and frames to frames and on converting from ODF (where rotation is unavailable in the destination) again convert to frames or textboxes according to whether fields are incliluded in the frame or not. Or just convert to frames and be done with it. Remember raise the compatibility flag too!
Enhance text box so that the text can include fields and objects has the advantage, that such solution would be usable in Draw/Impress and Calc too. It would solve bug 129061 and its duplicates and bug 35033. A request to allow fields in text boxes is bug 118348.
Re-adding UX as this turns out to be a very interesting discussion about text boxes vs. frames.
ODF supports the transform of the draw:frame for rotation we ought to implement frame rotation in the LO UI as it would offer a lot of function that is now missing. Otherwise agree with Luke that the additional work for the draw:shape text handling fields would be helpful, but I don't see them as conflicting. As noted there is a tradeoff in OOXML -- ODF interoperability and an obligation to alert to the loss of formatting when export save to non-native OOXML.
No need for more input from UX at this time.
Ok, the idea has been broadly accepted by those that have had a care to comment. So, where do we go from here to get traction on it? I.e. How do we go about getting it implemented?
IIRC Armin accomplished much of this for transform rotating images on the Writer canvas for bug 73797 with bounding frame resized to accomodate, but left additional work for actually rotating the frame (see 6.0 release notes). @Armin, could needed frame rotation for images also include frames in general as requested here?
> @Armin, could needed frame rotation for images also include frames in > general as requested here? I think yes, images are in a frame. Problem is more hat all these parametrizations in ItemSets need to be defined and done and need to work in the cores. Also UI/API questions, dialogs/Menus/Interactive. And - at top of it as icing - needs ODF-standard-conform integration to save/load, plus evtl. support in im/exported formats. Getting it painted/printed/exported to PDF is the easiest part. Bu tyes, the foundation layed with images can be taken as base here as orienation. HTH!