On Tue, 22 Sep 2020 at 20:47, Even Rouault <[email protected]> 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 > > > [email protected] > > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
