Issue #218 resolved
Former user created an issue


I'm not 100% sure if I just overlooked something, but I think that there is a bug in the pixel-position-calculation thing. In the openpyxl/shared/ the values for DEFAULT_COLUMN_HEIGHT and DEFAULT_COLUMN_WIDTH are set with '15.' and '51.85'. However, I think that they would need to be initialised with some value some the xlsx document (to be more precise, if you unpack a newly created document look in /xl/worksheets/sheet1.xml and you will find the following row:

<sheetFormatPr baseColWidth="10" defaultRowHeight="15" x14ac:dyDescent="0.25" />

So - if I get this thing right, the DEFAULT_ROW_HEIGHT would need to be initialised with defaultRowHeight and DEFAULT_COLUMN_WIDTH with baseColWidth.

I hope I didn't get anything wrong here how it works ;)

Comments (3)

  1. Torben W

    Hmm, I've been messing around a little bit more with the Cell.anchor() method... Something there seems to go totally wrong? If my cell A1 has a width of 20 (145 px), then the anchor-method returns a x-value of 28 px for B1.

    After some research it seems like the implementation of the algorithm to calculate the column width, is a misunderstanding of how excel handles column widths. The anchor-method aussumes that they are stored as "points". However as far as I found out, that's not the case. Excel uses some really f*cked up "unit" which is depending on the font and so on. I found this document which describes the behaviour in detail:

  2. Eric Gazoni

    Yeah, I really apologize for the crappy algorithm I implemented here, it was a requirement for a project from a sponsor, and works kind of ok on a default setup, but I rushed to write it and it certainly should be rewritten ;-)

  3. CharlieC

    Version 2.x uses a defaultcolumn width per worksheet that complies with the spec. Image positioning is still fucked up.

  4. Log in to comment