Subscribe to this thread
Home - General / All posts - Invalid Field when Printing - M9
631 post(s)
#06-Sep-19 18:04

I made contour lines from a DEM and want to print a portion of the lines. I created a layout, dragged the map in, and zoomed to the area. Then I set the Page Setup to ANSI D in the Adobe PDF print driver. When I hit the Print button in the print dialog box, I get an Invalid Field error. I haven't tried to print in awhile, but I think I'm doing it right.

See images.

Invalid Field Error when Printing.jpg
Schema for Invalid Field Error.jpg


8,846 post(s)
#06-Sep-19 20:02

That seems very odd.

A quick guess. Can you check for NULL geom values in the contours drawing? Best to use a query for this--

SELECT * FROM [Contours] WHERE [Geom] IS NULL;

--adjusting "[Contours]" to the name of the actual table or drawing.

If there are any NULL geom values, you could try deleting their records before printing, to see if that fixes the issue.



5,519 post(s)
#07-Sep-19 06:41

I agree it is odd.

One more thing to try: This isn't likely to fix the issue but because it is so easy to try, may as well do it. Try using a different PDF printer, like the Microsoft print to PDF that is part of recent Windows editions, or FreePDF.

After that does nothing to help, then I'd report the issue.


6,343 post(s)
#07-Sep-19 18:42

Off topic:

Sadly not many free PDF-printers support ANSI D AND to adjust quality to a reasonable small value AND manage to print raster data to such typical paper map formats. For instance Microsoft print to PDF does none of this and is no good choice.

So on the long run I guess Mfd 9 needs to implement it's own PDF exporter like Mfd 8 has.


5,519 post(s)
#08-Sep-19 07:06

So on the long run I guess Mfd 9 needs to implement it's own PDF exporter like Mfd 8 has.

As one more option, I suppose that's inevitable, if for no other reason to give people a mix of features not covered by current PDF printer options. But there are pros and cons to that.

But before that, it's important to make sure existing options are being used to their full potential. There's a role in that for Manifold and also a role for the operator.

From Manifold's side, for example, there's work underway to provide much better scaling of automatically generated layers, such as web served layers (Bing, etc.), when those are passed for printing by a layout. That's a case where the implied command to use a given resolution should not be taken literally, to pull hyper-detailed tiles at highest resolution from the server, so that labels and symbology end up too small based on the pixel resolution commanded. Manifold should make sure all such setup is done in a way that lets well-known PDF printers do their best.

As for the operator, there are probably twenty different PDF printer packages, a handful of well-known ones and a bunch of lesser known ones, and a mix of free and paid, all with different settings and options. Sorting out which is best for different tasks and how to operate them to best effect takes some tinker time.

A key thing to understand about PDF is that it is not a format: instead, it is a language for programming compatible display engines (including the use of hard copy "display" engines... printers). Different display engines interpret PDF code differently, with many differences of opinion between PDF display engine architects on how to interpret the many gray areas of PDF language.

PDF printer software is code-generation software: In effect, it automatically writes a program in PDF code that, when fed to a compliant PDF display engine, is supposed to generate a visual equivalent to what a printer would have printed based on the input. There too, people who write such PDF code generators have differences of opinions as to how PDF code should be written and what is "correct" PDF code in various optional or gray area situations.

Add to the above variability a random mix of code interpretation errors in PDF display engines and code writing errors in PDF code generators and you get the current situation where simple displays tend to come out about the same in most combinations, but if there is anything out of the ordinary, like collections of objects far beyond what's seen in a simple Microsoft Word page or zillion byte web server layers, you can get wild variability in the details of what comes out of the code generator / code interpreter pipeline.

The Microsoft PDF printer is pretty good, as are Adobe PDF printers, and some of the free PDF printers. But they are all far from perfect, and they are all far from perfect in different ways. The GDAL PDF code generator is likewise far from perfect, in yet a different way. Anything Manifold created as a PDF printer would also be far from perfect. There is a strong incentive to use well-known PDF printers because at least their vices are also well-known. For example, Manifold might create a module to enable PDF printing through GDAL, if for no other reason than to take advantage of GDAL's ability to add GeoPDF tags to PDF code.

One problem with that is to get GDAL's GeoPDF feature, you have to accept GDAL downsides. It could be much quicker and far better for users for Manifold to simply write a new generation Manifold PDF code generator, and add the features to that, like GeoPDF, that people want. It would certainly be more compact.

It's a shame the Microsoft PDF printer does not allow optional specifications of GeoPDF tags. Anybody know of a generic PDF printer that does?

631 post(s)
#10-Sep-19 20:38

I checked for NULL values as described. No results. Ran the DELETE anyway and got 0 results.

I have the Adobe PDF printer set as the default printer on my computer. I changed the size to print letter size and got the same Invalid Field error. Without changing the driver default I tried printing to a 'real' printer and got the same error. I tried changing the default printer on my computer to a real printer, reset the Page Setup using the hardware printer, and tried to print - got the same error. I left M9 open, closed that file, and opened another. Created a layout with default everything and it printed as expected. So I went back to the original problem child and got the same error. On a whim I panned to a less complicated part of the map within the Layout and it printed as expected. So I panned back to the contour lines and it would not print. So i panned to the edge of the contour lines and it would not print. So I panned further away and it printed. The problem seems to be in the contour lines.

The contour lines and labels were created with the following query...

-- $manifold$

-- Transform - Contour Lines - Add Component


-- This first part creates an empty table and drawing. 

-- Offsets should be adjusted beforehand, but results can moved with the Shift transform

CREATE TABLE [West Bandera County DEM Contour Lines] (

  [Geom] GEOM,

  [Value] FLOAT64,

  [mfd_id] INT64,

  INDEX [mfd_id_x] BTREE ([mfd_id]),

  INDEX [Geom_x] RTREE ([Geom]),

  PROPERTY 'FieldCoordSystem.Geom' 'EPSG:26914,mfd:{ "LocalOffsetX": 481845, "LocalOffsetY": 3277229 }'


CREATE DRAWING [West Bandera County DEM Contour Lines Drawing] (

  PROPERTY 'Table' '[West Bandera County DEM Contour Lines]',

  PROPERTY 'FieldGeom' 'Geom'


PRAGMA ('progress.percentnext' = '100''progress.percentinsertsource' = '80');

INSERT INTO [West Bandera County DEM Contour Lines] (




-- The following uses a 

-- minimum value of 1360 feet (414.528 meters), 

-- max of 2340 feet (713.232  meters), and 

-- creates a contour line every 20 feet (6.096 meters)

-- The source of data for this example is the Image DEM 

FROM CALL TileContourLinesPar([Image], CALL ValueSequence(414.528, 713.232, 6.096), true, ThreadConfig(SystemCpuCount()));

-- The following creates a new field for Feet in Float64 but truncated to the integer

-- Schema


ALTER TABLE [West Bandera County DEM Contour Lines] (

  ADD [Feet] FLOAT64

    AS [[ RoundDecs([Value]*3.28084, 0) ]]


-- Finally create labels for contour lines in feet

CREATE LABELS [Contour Labels] (

  PROPERTY 'Drawing' '[West Bandera County DEM Contour Lines Drawing]',

  PROPERTY 'FieldText' 'Feet' & ' Feet'


This query was copied from a previous project which, given my query skill level, had to have been adapted directly from this forum. I had forgotten to reset the offset values so I transformed the contour lines in to position with Shift. Then I went to the previous project and tried to print a layout with contour lines and it printed as expected. The problem seems to be with the contour lines within this one file. I'm going to start over with the project and see what happens.

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.