| Summary: | Need sub-0.1-milimeter position and size resolution | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Eyal Rozenberg <eyalroz1> |
| Component: | Draw | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | vsfoote |
| Priority: | medium | ||
| Version: | 5.3.3.2 release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=152079 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 100023 | ||
|
Description
Eyal Rozenberg
2017-07-05 17:42:22 UTC
Internally the canvas already positions to 10^-5m increments--or 1/100mm--but by design we limit the GUI widgets to just 2 decimal places. So at best we can position in 10^-4m increments, or the rounded conversion from other measure units (TWIPS, pts, px, ch). For now the project calculates positions as 32-bit integers. Achieving higher precision requires we move to floating point calculations which is being looked at but is a long way from implementation. For now--increasing the UI to 3 decimal places of duplicate bug 44267 is about as far as we can go to expose the limited precision possible with current framework. =-refs-= bug 95812 bug 103322 *** This bug has been marked as a duplicate of bug 44267 *** (In reply to V Stuart Foote from comment #1) > Achieving higher precision requires we move to floating point calculations > which is being looked at but is a long way from implementation. Or moving to 64-bit integers, which, while costing more space, should present much fewer transition issues relative to going floating-point. |