Subscribe to this thread
Home - General / All posts - Invalid Field when Printing - M9
685 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

9,111 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,765 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,360 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,765 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?

685 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.


8,884 post(s)
#25-Sep-19 12:05

The 'FieldText' property for labels should contain the name of an existing field, it cannot contain an expression. Right now it contains 'Feet Feet', the table does not have a field with such a name, that's likely the source of the error.

It seems you want to set label text to the length in feet + the word 'feet'. If so, one way to do this is to add a second computed field which would produce text (untested code):




    AS [[ CAST([Feet] AS NVARCHAR) & ' Feet' ]]


...or to make the computed field text in the first place:




    AS [[ CAST(RoundDecs([Value]*3.28084, 0) AS NVARCHAR) & ' Feet' ]]


Make labels reference the text field in either case.

We are considering allowing labels to use an expression with simplified syntax (which is half of the point, because if you are fine with SQL syntax and / or want some involved computations, use a computed field, no need to reinvent the wheel). Something like '[Feet] Feet', but possibly something a little more involved.

685 post(s)
#25-Sep-19 23:20

Maybe that's the reason why my labels aren't what I expected. I'll look into that. Thanks.

685 post(s)
#26-Sep-19 16:01

I created the new text field for the labels and then created labels by right clicking and selecting New Labels. I used the text field, but the labels do not appear when dragged on the map. To check my process I created labels for a different layer and those appeared as expected.

Not that it matters but the Feet field in the table is an elevation value for the contour line, not length.


5,765 post(s)
#27-Sep-19 09:33

I created the new text field for the labels and then created labels by right clicking and selecting New Labels. I used the text field, but the labels do not appear when dragged on the map.

I assume you mean you used the Schema dialog to create a new text field in a drawing's table... is that correct? If you open the drawing's table, are there any values in that text field, or are the values for all the records empty?

How many records are in that drawing? What are the geoms (points? lines? areas?) for those records?

Suppose they are points... if you drag and drop that drawing into the map, do points appear where they should be for each record? (etc., for line and areas). If the "host" object for the label does not appear in view, the label won't either.

If the labels were created for lines, could it be the labels for the lines are not in view, and that if you pan and zoom the viewport they come into view? One way to check that is to open the drawing's table, select a record for which you have a non-NULL value in the text field you use for the labels, and then in the map, right click on the labels layer and choose Zoom to Selection. If there is a label, that will show it.

Have you checked the Style for the labels? If label text is white, the labels will seem to be invisible with default white background.


8,884 post(s)
#01-Oct-19 14:26

Adding a bit to Dimitri's post: labels for contour lines will likely eventually appear if you keep zooming in. That they do not appear until individual segments get big enough is a deficiency of our rendering algorithm which is currently too simplistic - this is going to be improved. Until then, consider creating a new drawing with a couple of points for each contour line and creating labels for that drawing.

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