> On 18 Feb 2016, at 15:43, Roberto Nibali <[email protected]> wrote: > > Hi > > On Thu, Feb 18, 2016 at 11:03 PM, Gilad Denneboom <[email protected] >> wrote: > >> Probably just a type-o. It should be renamed POINTS_PER_MM, which is indeed >> 2.83465. >> > > At some point in my code I defined those values as such: > > private static final float POINTS_PER_INCH = 72; > private static final float MM_PER_INCH = 25.4f; > private static final float MM_PER_POINT = MM_PER_INCH / POINTS_PER_INCH; > private static final float POINTS_PER_MM = POINTS_PER_INCH / MM_PER_INCH; > > I used them as abstraction hints for an API call to position data matrix > and other stuff by relative metric measurements. Example: > > pdf.addDataMatrix(srcDoc, page, "Sometext", 87 * POINTS_PER_MM, PAGE_H - 60 > * POINTS_PER_MM - DM_H_ABS, 1f);
It would be better to just transform the CTM, when you want relative positioning, use a translation matrix, when you want to work with a different unit of measure, use a scaling matrix. PDF gives you the ability to work in any units you want. — John > This for example would mean that the text had to be positioned > 87millimeters from the left hand side and 60 millimeters from the top of > the page minus the expected height of the data matrix. It allows the user > of the API to directly use typical CI/CD guideline measurements in metric > format, while the drawImage() method of the PDPageContentStream object > inside PDFBox always expects points in floats as input. > > Your mileage might vary on this level of abstraction. I found them to be > very useful and certainly wished that those be accessible via public > interface instead inside PDFBox. > > Cheers > > Roberto --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
