Opened 6 years ago
Closed 6 years ago
#7185 closed defect (fixed)
Wrong text size when converting DXF to PDF
Reported by: | Alan Thomas | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SF | Version: | svn-trunk |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
I converted autotest/ogr/data/leader-mleader.dxf
to PDF using ogr2ogr:
ogr2ogr -overwrite -f "PDF" leader-mleader.pdf "C:\Projects\gdal\autotest\ogr\data\leader-mleader.dxf" -dsco STREAM_COMPRESS=NONE
The text sizes in the resulting PDF are excessively large.
Here's an example style string from ogrinfo -al
on the original DXF (this is the style string for the big red text you see in the page):
LABEL(f:"Arial",t:"Apples",p:2,s:1g,c:#ff0000,a:10)
The font size in the resulting PDF is 1000.000000
. Looking through the code, it's unclear to me where the multiplication by 1000 is taking place. I'm not sure what the correct size is; the text should be 1 DXF unit high, as implied by the style string, but a value of 1.0 in the PDF is too small.
(As a side note, each text object is associated with a grey circle, which seems unwanted.)
See also #5910.
Change History (5)
comment:1 by , 6 years ago
Description: | modified (diff) |
---|
comment:3 by , 6 years ago
Your knowledge about typographic issues goes far beyond mine. My quick research of what 'em' confused me (could'nt really make a sense of the wikipidia page). I'll defer to your judgement on the best outcome. It is obvious that 1:1 equivalence between formats is somewhat utopic and GDAL should only try to a reasonable effort to preserve appearance during conversions, and we probably don't want to implement typographic rules (in the case we'd go to that road, we'd better rely on third-party libraries specialized in that domain to get font metrics). Historically the OGR feature style spec has been (I believe) developed mostly for the need of the MapInfo file, so it could make sense to use the definition of font size used by MapInfo (which I don't know), and do our best with it. Adding specific fields to override/precise that basic metrics could also be an option.
comment:4 by , 6 years ago
This is a useful primer for the difference between cap height and font size (em height).
In the New Year I will post to the mailing list about a range of proposed updates to the feature style specification.
Upon investigation, it became apparent that the PDF writer's text output code was in need of some attention. I've got a patch that
I'll upload the patch once the tests have been fixed.uploaded at https://github.com/OSGeo/gdal/pull/288Unfortunately it is problematic to get the DXF font size to exactly match PDF font size. CAD software tends to measure text size by the capital height, whereas most graphics and word processing applications, including PDF, use the em height. Converting between the two values is only possible if you know the metrics of the specific font in use. I can see several options here:
FontDescriptor
data to obtain font metrics and convert em height to cap height. In the PDF writer, use built-in metric data for the 14 standard fonts to perform the reverse conversion. This will cause problems if we ever have a driver for a format that uses em height but does not store text metrics (SVG being one that comes to mind - possibly even some of the existing drivers using style strings).