1 Point = 1/72 inch 1 Twip = 1/20 point = 1/1440 inch
In Aspose.Words public methods and properties all measurements are now in points. The datatype of the value is double. This was made to be similar to Microsoft Word Object Model methods and properties.
Internally in Aspose.Words, in the binary DOC, WordML and RTF formats the measurements are all stored in twips as integer values.
We are looking for your feedback whether Aspose.Words public API should stay in points or be changed to twips at some stage in the future (for example in V4.0).
The benefits of changing to twips are:
Integer arithmetic will result in a bit faster and a bit more compact component. No conversions and no code to do those conversions.
Twips could become more "popular" because of WordML.
I can't see any situation where I'd need the accuracy of the smaller units of twips but I would not want to exclude the possibility in the future so I'd vote for twips for the greater accuracy and finer granularity.
At the same time, I'd suggest supplying static/shared functions TwipsToPoints and PointsToTwips- even though these functions are trivial- they will save programmers the lookup chore every time they have to convert.
twips or points technically give you same accuracy of twips. You can specify 5.6 points for example, that translates to 112 twips.
There is WordConvert class already with static methods. It does not have point to twip conversion yet because twips are not used in the public interface yet.
Ok, since no one seems to be posting or has a strong opinion on this subject. I like the idea of exposing/using twips. Perhaps you could expose and have both twips and points.
As points are already built in, there seems little point in removing them. It might however be a good idea to add twips as well if twips are used internally anyway.
If the unit of measure for the existing methods and properties was simply changed, this would certainly create a lot of work for all of us who use the existing points. We would need to manually inspect all of our code, which would be error prone.
Adding twips as an alternative could be useful. Perhaps an existing method could have an alternative, with …Twips added to the method name. Much like Microsoft did with the 32 bit API where they added Ex to the 16 bit names.