Created attachment 200956 [details] Demo Excel file, to be opened in Calc After importing an Excel spreadsheet with a checkbox control that is anchored to a cell, the checkbox is then shown as anchored on the page instead. For some documents this leads to a wrong position of the checkbox on the sheet and thus makes it unusable.
Open the file and insert a row above the checkboxes lines. Checkboxes are not in line with the options for them (checkboxes are wrong anchored to page). Confirm with Version: 25.2.3.1 (X86_64) / LibreOffice Community Build ID: d8d1af5f77df955194e52baabe19324532ac8e8b CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
The anchor is imported as on page, not as on cell. If we changed anchor to cell, everything works fine. It is the same in Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: a0dd1c4a363b9d4d2a16ff82acc3ada0c075cb65 CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Also in Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community Build ID: 35f19e5cb93ce218787904e99c2bedfd40e725cc CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded and in Version: 7.0.7 and in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
(In reply to BogdanB from comment #2) > The anchor is imported as on page, not as on cell. > > If we changed anchor to cell, everything works fine. I'd like to work on this issue. Would you have some code pointers? I have achieved anchoring the form controls to the cell during the import, but it didn't really solve the issue so I'm thinking I didn't do it right.
(In reply to Johann Lorber from comment #4) > (In reply to BogdanB from comment #2) > > The anchor is imported as on page, not as on cell. > > > > If we changed anchor to cell, everything works fine. > > I'd like to work on this issue. Would you have some code pointers? > I have achieved anchoring the form controls to the cell during the import, > but it didn't really solve the issue so I'm thinking I didn't do it right. Maybe submit your code as a WIP patch, so it's easier for others to comment.
Sorry to disturb you but the computer service company that employs you has been selected on the basis that they have skills on LibreOffice codebase. As it's not the case your employer should pay for services to real free software companies with certified developers listed here: https://www.documentfoundation.org/certified-developers/
(In reply to Arnaud Versini from comment #6) > Sorry to disturb you but the computer service company that employs you has > been selected on the basis that they have skills on LibreOffice codebase. > > As it's not the case your employer should pay for services to real free > software companies with certified developers listed here: > https://www.documentfoundation.org/certified-developers/ I am a bit confused by your comment, because as far as I know the company that hires me does have people with good skills on the LO codebase. I am just a fairly new hire, still learning and trying my best to gain knowledge on this codebase. Are you really basing your judgement solely on my own interactions here, or do you have some knowledge on my employer that I do not? Either way, the junior developer that I am can't do much about it, and I am personally more interested in solving the issue at hand and getting better at my job. (In reply to Buovjaga from comment #5) > (In reply to Johann Lorber from comment #4) > > (In reply to BogdanB from comment #2) > > > The anchor is imported as on page, not as on cell. > > > > > > If we changed anchor to cell, everything works fine. > > > > I'd like to work on this issue. Would you have some code pointers? > > I have achieved anchoring the form controls to the cell during the import, > > but it didn't really solve the issue so I'm thinking I didn't do it right. > > Maybe submit your code as a WIP patch, so it's easier for others to comment. I am currently on vacation, I'll be back next week and will submit my WIP patch then.
(In reply to Johann Lorber from comment #7) > (In reply to Arnaud Versini from comment #6) > > Sorry to disturb you but the computer service company that employs you has > > been selected on the basis that they have skills on LibreOffice codebase. > > > > As it's not the case your employer should pay for services to real free > > software companies with certified developers listed here: > > https://www.documentfoundation.org/certified-developers/ > > I am a bit confused by your comment, because as far as I know the company > that hires me does have people with good skills on the LO codebase. I am > just a fairly new hire, still learning and trying my best to gain knowledge > on this codebase. Are you really basing your judgement solely on my own > interactions here, or do you have some knowledge on my employer that I do > not? Either way, the junior developer that I am can't do much about it, and > I am personally more interested in solving the issue at hand and getting > better at my job. > > (In reply to Buovjaga from comment #5) > > (In reply to Johann Lorber from comment #4) > > > (In reply to BogdanB from comment #2) > > > > The anchor is imported as on page, not as on cell. > > > > > > > > If we changed anchor to cell, everything works fine. > > > > > > I'd like to work on this issue. Would you have some code pointers? > > > I have achieved anchoring the form controls to the cell during the import, > > > but it didn't really solve the issue so I'm thinking I didn't do it right. > > > > Maybe submit your code as a WIP patch, so it's easier for others to comment. > > I am currently on vacation, I'll be back next week and will submit my WIP > patch then. Hi Johann, If you have good knowledge of the LibreOffice calc in your company you should not have to ask the community for code pointers, no ? Anyway I'm ok as I said on my blog I'm ok to discuss with your company during the LibreOffice conference in Budapest. If you want to know what's wrong with LibreOffice in your company feel free to see my latest slides https://events.documentfoundation.org/libreoffice-conference-2024/talk/WP7XPU/ and also articles on https://versini.ovh Anyway don't feel it's against you, it's of course not. Btw you should take the ticket and change its status
I do not have to ask the community no, but isn't an open-source community based on knowledge exchange and helping each other out? Should I bother my coworkers which are busy on many other fields when I could ask the loads of expert present on this forum (isn't it partially why this forum exists)? I don't know which kind of history you have with my company, but I think you are talking to the wrong person (again, just a junior developer here) and we are definitely having this conversation in the wrong place. I hear your arguments and I will look up the material you sent, but I think if we want to keep this talk going we should go through private channels rather than pollute this forum further.
You're not an individual asking help, You're a professional asking support from real experts that have customers too to help you and your company should have this expertise ! Your bug is probably for the french government administration and they pay you to fix the bug, isn't it ? You're saying that people from your company have other things to do so you ask experts from other companies to help you and show you the code ! They also have customers who pay them, and those customers are paying for LibreOffice certified developers. Should you bother your coworkers instead of the LibreOffice ecosystem for a work paid by Linagora customers ? The answer is yes ! You should remember you're representing your company here... Linagora is well known for not playing well with free software ecosystem and you're confirming it ! Of course you can ask but they have work to do too for THEIR customers. Yes it's not the place to talk about that and I'm available on matrix and telegram as well as during libocon.
(In reply to Arnaud Versini from comment #10) > Your bug is probably for the french government > administration and they pay you to fix the bug, isn't it ? Nope. And don't worry, you succeeded in turned my away from ever interacting on this forum again. Cheers.
Wasn’t my goal, anyway as you want
https://gerrit.libreoffice.org/c/core/+/190166 > And don't worry, you succeeded in turned my away from ever interacting > on this forum again. This was rash, so I'd like to retract it. For those of you who would like to keep this side-conversation going in an amicable way, I am open to discuss it through matrix, email, IRC or whichever way you prefer. Now, here, I'd like to focus on the issue at hand. I will refrain from asking for any kind of help as much as possible, as I understand that it isn't very welcome coming from me because of my affiliation with my employer. So here are my notes and observations: In my WIP patch I have included logic to anchor form control shapes to the cell. My understanding is that, in Excel 2010 (v.14.000, potentially since Excel v.5 but I haven't been able to check that yet), for these legacy shapes, the presence of the Anchor property (in the VML file) infers that the shape is anchored to the cell on the top left corner of the rectangle defined by this property (e.g.: if <x:Anchor>2, 20, 1, 2, 4, 20, 2, 10</x:Anchor> then the shape should be anchored to cell(2, 1), the rectangles top-left to bottom-right being (2,1) to (4,2)). From my research and observations, the Anchor property is not present when the VML shape has been anchored to the page through Excel 2010. Please correct me if you know of contrary examples, I very well could be wrong. I also haven't been able to test with other Excel versions yet besides Excel 365 (v.16.030), which uses MoveWithCells and SizeWithCells properties. This is why I have tied my patch as closely as possible to the ClientData parsing process, which allows us to check on the Anchor property and have access to the worksheet helper. As of now, my patch doesn't check which Excel version generated the xlsx file, neither is that kind of check done elsewhere as far as I am aware. Therefore the patch is very incomplete, but simply allowed me check how I could anchor the control forms to cell and if that could solve the other following issue: > I have achieved anchoring the form controls to the cell during the import, > but it didn't really solve the issue so I'm thinking I didn't do it right. The reason I made this comment is because in my tests I have observed another issue regarding form controls during the import process, when the sheet's columns and rows' size are not default, then it looks like it messes up the positioning of those shapes in the import result. The origin of this misplacement is yet to be 100% confirmed, I am going to need to dig a bit more for that. Since the original poster mentions a problem with positioning of the shapes resulting from the anchoring issue, I assumed that we were talking about the same positioning problem. Now I understand that the original post meant that the position of the form control is not updated with the cell's position, if we fix the anchoring issue it does indeed solve that. The main complexity here is defining exactly how each version of Excel references cell anchoring in the VML file. I will open another bug for the form control positioning issue as it seems to be a different a problem.
After digging into it a little more : - my original claim that the Anchor property defines cell anchoring is wrong - Excel does in fact use MoveWithCells (and SizeWithCells) but not in the way described in its own documentation (https://learn.microsoft.com/en-us/dotnet/api/documentformat.openxml.vml.spreadsheet.movewithcells?view=openxml-3.0.1) I have generated test files with checkboxes (form controls) with every major version of Excel since 2007 and observed the same behaviour throughout. I am including here 2 test files created with Excel 2013, both have the legacy checkboxes but in one the checkboxes have the properties Move with cell and Size with Cells enabled in Excel, the other file doesn't. If you download the files, unzip them and open xl/drawings/vmlDrawing1.vml : - the checkboxes which had Move and Size with cells enabled in Excel do not have those properties in the ClientData block - the checkboxes which had Move and Size with cells disabled do have those properties declared in the ClientData block, but not assigned. Now I am still a bit careful about these findings because they are opposite to MS own documentation which states "If this element is specified without a value, it is assumed to be true.", so the exact opposite of what I've seen. If somebody else could do the test and confirm that I am not crazy that would be of great help. If that behavior is indeed confirmed then I have solution ready at hand in the WIP patch linked in my last comment.
Created attachment 202834 [details] Checkboxes Testfile - Excel 2013 - Move and Size with Cells enabled
Created attachment 202835 [details] Checkboxes Testfile - Excel 2013 - Move and Size with Cells disabled