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

[Nyall Dawson]

On Tue, 22 Sep 2020 at 20:47, Even Rouault <even.rouault at spatialys.com> wrote:
>
> Nyall,
>
>
>
> 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 pdfcreatefromcomposition.cpp
>
>
>
> 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.

Ok thanks! I can confirm that removing the writing of user units fixes
the problem.

PR opened at https://github.com/OSGeo/gdal/pull/2961

Nyall


>
>
>
> Even
>
>
>
> >
>
> > 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
>
> http://www.spatialys.com