Description: While making a .pdf form, text boxes had to manually be added to each cell that required a response. A feature that would fill all selected cells with a text box (that would match the sizing and margins of the cell) would be helpful and result in a more professional appearance. Steps to Reproduce: 1.Select Cell 2.Choose text box under forms tools 3.Draw text box in cell Actual Results: Inconsistent textbox sizes due to operator error and extended time of repetition. Expected Results: If a "fill cell with textbox" (or similar) feature could be added, a number of cells could immediately be filled with consistently sized textboxes. This would improve efficiency when making PDF forms. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.3 Calc: threaded
It is possible to fit the control to the cell with: 1. right-click > anchor > to cell (resize with cell) 2. right-click > fit to cell size After that, copy-pasting the cell to another cell keeps the properties. (Although note recent regression bug 158561.) However, it doesn't allow pasting them to _several cells at once_. (Same issue with e.g. images with the same settings.) Do you think it would be enough to allow pasting objects to a cell range, possibly as a Paste Special operation, resulting in a duplicated object for each cell in the range? I think it would make sense to have that option (since the object is anchored _to cell_), and it would be enough of a workaround (rather than implementing a new function as specific as "insert control in all selected cells with cell anchoring (resize with cell) and size fitted to cell" aka "fill cells with this control"). Design/UX team, thoughts? This feels more like a bug to be solved ("can't copy/fill objects anchored to cell to a cell range") rather than an enhancement request. Writer already allows that as a default with e.g. images in a table cell, anchored as character or paragraph. Can be tested with attachment 191262 [details]. Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 43967453e15e1d054972a7586cfef8f8e0866270 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #1) > Do you think it would be enough... => NEEDINFO > Design/UX team, thoughts? This feels more like a bug to be solved ("can't > copy/fill objects anchored to cell to a cell range") rather than an > enhancement request. > Writer already allows that as a default with e.g. images in a table cell, > anchored as character or paragraph. You can multi-select fields and paste it all together. But still a workaround. Question is whether you can expect to copy one item into many cells like numbers or text (and expect probably adjustments to the content). IMO a nice-to-have but not crucial thing, but probably some (technical) reasons to not do it. If the field is enabled you move it around with the arrow keys - it offsets from the anchored position, rarely but possibly intended. Have I suggested to change the defaults of anchoring and fit to size?
I applied the first workaround mentioned and it worked perfectly (with minor bouts of user error). For 35 insertions it took about 10 minutes. To complete the form, I have another 250 or so to go. It seems like the bug fix portion is something that would be beneficial to the program as a whole. But I am looking at a basic function of form creating from an end-user point of view. IMO it still seems best to me as an enhancement. It would be a clear cut and efficient way to designate cells as fillable text boxes would be a marketable feature for form-creation enthusiasts (or slaves- depending on the case). Perhaps the feature could simply be something like a macro "under the hood" that would insert textbox, anchor to cell-resize with cell, and fit to cell size for all selected cells. The programming could do it cell by cell if the universal change has too many issues.
(In reply to Dave from comment #3) > I applied the first workaround mentioned and it worked perfectly (with minor > bouts of user error). For 35 insertions it took about 10 minutes. To > complete the form, I have another 250 or so to go. Sounds like a topic for Base or XML Forms. https://www.libreoffice.org/discover/base/ https://help.libreoffice.org/6.1/en-US/text/shared/guide/xforms.html https://wiki.documentfoundation.org/images/b/b4/XML_Formulare.pdf (not sure there is an English version available but the topic is driven by a dedicated person who'll likely support you)
In other words, the form creation tools within Calc are more symbolic than features. It just means that if one works in Calc, then the suite design is that the work be transfered and adapted to either Base or Writer for the form creation aspect. That is OK, but in my workflow, one program enhancement (or bug fix) would move my efforts from workarounds to work done at the final stage of form creation.
(In reply to Dave from comment #5) > In other words, the form creation tools within Calc are more symbolic... Take my advice as an alternative workflow. What do you suggest to do?
Created attachment 191291 [details] Convert Cell to Text Box Possible insertion. Maybe there is a better graphic or function name?
I apologize for not communicating clearly. It is my first time making a suggestion to a program that I use daily and appreciate. The "symbolic" statement was not meant to be snarky, but an attempt to clarify that the point of Heiko Tietze was that the design of the suite due to whatever programming, practical, and/or popular use reasons was to pass the form to Base or Writer for final form processing before printing to .pdf (in my application). Which I am OK with, but the enhancement suggestion for me would work better. I have attached a graphic that reflects the idea that I proposed originally if that can be a help. I do not pretend to understand how things work, but the initial thinking expressed in this thread seems to indicate that it is a more complicated problem.
I realise now that the general "enhancement" I suggested in comment 1 used to be available but there was a regression. See bug 121443: it used to be possible to copy one control in a cell to many cells (although a control "fitted to cell size" might not have been caught back then; can be tested with something clearly within the bounds of the cell). So, even though fixing that regression would make the workaround easier, let's focus here on what you suggest: inserting several same controls at once, filling the cells in the selected cell range. The design/UX team can decide if that's something that needs to be done in core, or should be done via macro / extension.
(In reply to Heiko Tietze from comment #2) > Have I suggested to change the defaults of anchoring and fit to size? Might be bug 154057 comment 6, but that would mainly apply to the special case of inserting a button with the Hyperlink dialog, I guess?
We discussed the topic in the design meeting. Changing the default might be an option but probably not in general (lists usually take more space than one cell) and the combination of the two commands could be done per macro too. And changing the default would not solve the issue here where hundreds of controls should be positioned. A reasonable expectation in this case is to paste the formatted control and progress to the next cell per arrow - which fails as arrow moves the control. We could block this for cell-anchored controls. In a nutshell: keep the default but don't move cell-anchored controls via arrow keys and make them behave like any other content. This allows quick keyboard only copy/paste operations.