[gdal-dev] Confusion regarding GeoPDF composition.xml units

Even Rouault even.rouault at spatialys.com
Tue Sep 22 03:47:43 PDT 2020


I don't necessarily have much to add to Andrea's excellent analysis. So the value of <Width> 
and <Height> are interpreted as "width/height in user unit", and written unmodified for the 
MediaBox array.
The <DPI> value is multiplied by 1./72 to set the UserUnit PDF setting. See line 1015 of 

The WRITE_USERUNIT creation option is currently used only for the CreateCopy() interface 
of the driver (using a raster as a source), but not in Create() from composition XML. 
If you want to experiment not writing it, it is a matter of disabling line 1127 of 
pdfcreatefromcomposition.cpp, but using <DPI>72</DPI> will cause UserUnit to be set to 1.0, 
which is the default value.

I remember having headaches with those concepts when developing the driver. Perhaps the 
interface is not optimal.
Part of the confusion might also come from specific working in CreateCopy() mode where 
the driver tries to generate a PDF with settings such as when opened by the read side of the 
driver, the reported dimensions in pixels of the PDF match the one of the raster provided to 
CreateCopy(), and the DPI concept makes sense there.
But in Create from composition mode, where the sources are not necessarily raster, the 
equivalence of UserUnit = DPI / 72 might be less relevant.


> While attempting to fix https://github.com/qgis/QGIS/issues/33465 I'm
> running into some confusion about the meaning of pdfCoordinateType
> values in GeoPDF composition.xml files.
> The example composition.xml from
> https://gdal.org/drivers/raster/pdf.html includes:
> <Page id="page_1">
>         <DPI>72</DPI>
>         <Width>10</Width>
>         <Height>15</Height>
> ....
> This would suggest to me that the Width and Height (and accordingly
> all pdfCoordinateType) values are in inches. But that doesn't match
> with the actual behavior I'm seeing, where it seems like Width/Height
> and other pdfCoordinateType values need to be specific in pixels (i.e.
> size in inches * dpi).
> Actually it's a bit more complex than this, because regardless of the
> DPI specified for the page, the width/height have to be specified in
> size in inches * 72! (i.e. there's a hardcoded 72 dpi assumption
> somewhere).
> Can anyone clarify exactly how PDF coordinates and sizes should be
> calculated in composition.xml?
> Thanks!
> Nyall
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200922/445c9cb9/attachment-0001.html>

More information about the gdal-dev mailing list