Style definitions are reworked with style data for individual elements compartmentalized into subobjects more closely reflecting the structure of the rendering pipeline. Old style definitions may not work. Size values are no longer split into Xxx / XxxPct properties depending on whether they are absolute or relative, and are instead stored as strings. Size values support 'x@' syntax, with '5@' meaning '5 points bigger than the original size' and '-1@' meaning '1 point smaller than the original size'.
Style dialog is reworked to split style data into tabs. Style elements on each tab are turned on or off and customized independently. Tabs for most style elements allow specifying custom colors or a custom size.
Style dialog displays tooltips with symbol names for grids and allows filtering grids by typing partial symbol name. The name for a font character is set to the numeric character code.
Point styles allow specifying offset and angle for point symbol. Label styles allow specifying offset and angle for label symbol. The offset is only applied for labels rendering near points.
Point styles apply halo and shadow separately to point symbol and to point box. Halo and shadow can be applied at the same time. Label styles apply halo and shadow separately to label text, to label icon and to label box. Line styles allow applying halo. Area styles allow applying halo to border.
Line styles for dashes and dots are collapsed into a single style with a customizable dash pattern. The dash pattern is a sequence of pairs separated by commas: dash width, space width, ... . Each value can be specified either in absolute points ('3' = 3 points) or in relative points ('3@' = 3 point more than the line size) or in percents ('300%' = 3 times the line size).
Line styles specify dash cap as a choice between 'flat' (default), 'round', 'square' and 'triangle'.
Area styles allow specifying formatting for regions of the area of specified width that extend into or outside of the area. The 'Inner' tab specifies formatting for the region that extends from the area border into the area. The 'Inner Border' tab specifies formatting for the border of that region that is inside the area. The 'Outer' tab specifies formatting for the region that extends from the area border outside the area. The 'Outer Border' tab specifies formatting for the border of that region that is outside the area. The distance to extend into or outside is specified on the first tab as 'Inner / outer offset', the same distance applies in both directions.
(Note: inner and outer regions are computed dynamically with the help of the graphics card driver. We worked hard to optimize the code we use for this and several last internal builds saw tremendous speedups from the first iterations. However, ultimately, dynamic computations of that nature do not come for free. Using inner / outer regions will typically increase rendering times by 50-200%, depending on the data and on other formatting options in use. Everything else being the same, higher offset values will result in better performance - because with higher offset values we have more room to simplify input geometry for the driver.)
Line styles allow specifying formatting for left and right offset lines. What's 'left' and what's 'right' depends on the orientation of the line. Left and right offset lines for a closed loop coincide with inner and outer borders if the closed loop was treated as an area. If the original line crosses itself or goes in different directions from the same location or converges into the same location from different directions, left and right offset lines for a rendered shape may not agree with left and right offset lines computed on the original geometry. (We are going to provide geometry functions to compute offset lines on the geometry values in the future.)
Point styles can be bitmaps. To specify a bitmap to use as a point style, click the button with the dropdown menu above the point symbol grid, invoke 'Images...', then select one or more image files. The dialog will import all files and display them in the grid. The process of the import tracks its progress and can be canceled. Bitmap styles are limited to 128 x 128 pixels, but the import will read images up to 1024 x 1024 pixels and scale them down proportionally. Files bigger than 4 MB are ignored without being read. Image pixels can be completely or partially transparent.
Bitmap pixels are encoded as lossless WEBP (which really helps keeping the size small in case there are many similar colors) and are stored in the style JSON as a BASE64 string. Storing bitmap pixels directly in the style JSON allows freely transporting bitmap styles between systems / sending data formatted using bitmap styles via email, etc, with no need to bundle the original image files.
Halo and shadow for bitmap styles are rendered as if the style was a square. (We might change this in the future to follow the shape of the bitmap image.)
Area styles can be bitmaps. Bitmaps for areas are rendered on top of the background color (which can be set to be transparent).
The rendering engine used for reduced graphics mode is better separated from the rending engine used for normal graphics mode, and is simplified to use a fixed point / line / area / label style and use as few resources as possible. (With so many additions coming to the normal graphics mode which the reduced graphics mode couldn't have, it was increasingly harder to justify the reduced graphics mode not rendering, say, points formatted as bitmaps or points formatted as SVG paths, but still rendering points formatted as built-in shapes differently depending on shape. The purpose of the reduced graphics mode is to produce *some* display in scenarios where the normal graphics mode is - temporarily - unavailable, so we pruned all attempts of the reduced graphics mode to play smart and forced it to produce a very simple picture as fast and robust as possible.)
Style dropdowns save last used order and view mode.
The query engine better optimizes searches on BTREExxx indexes on tables from remote databases. (The nature of the change is that the query engine passes additional data with the search request describing what specific filtering it wants to perform, and this helps the dataport for the remote database translate the request into a command that optimizes better on the database engine. The difference in many cases is pretty big. For example, before the change requests on non-clustered indexes in SQL Server optimized way worse than requests on clustered indexes, and after the change they optimize well in both cases - and both in many cases way better than before.)
SQL Server dataport treats all views as updatable (because there is no way to tell whether a SQL Server view is updatable or not - unlike with other databases - there is a semi-standard way to declare that, but SQL Server always puts 'the view is readonly' there even if the view is actually writable).
SQL Server dataport no longer attempts to determine the SRID for each new GEOMETRY or GEOGRAPHY field it sees and instead determines the SRID when the table with the field is opened or is otherwise used (eg, gets used to create a drawing). The dataport also no longer creates a virtual drawing for each new geometry field. (This removes long waits on initial connections to SQL Server.)
There are new query functions to aid working with parts of tables coming from remote databases and other data sources:
- TableCache - takes a table and caches its data, allowing either reads or both reads and writes depending on the parameter. The result table has all indexes that were in the original table. Writes to the result table update both the original table and the cache.
- TableCacheIndexGeoms - does the same as TableCache and also adds an RTREE index on each geometry field.
(With these new functions and improvements in the query engine mentioned above, one can (a) write a SELECT ... WHERE x=y query in Manifold which hits the index on the database - and have that query run fast on the database, then (b) wrap the result into a write-through cache using TableCache or TableCacheIndexGeoms, (c) display the result as a drawing and work with it - with any changes to the drawing being seamlessly transported through the cache to the database.)
(Fix) Reading GEOGRAPHY data from SQL Server via spatial index no longer sometimes fails because query rect exceeds the -180..180 / -90..90 range.
(Fix) Writing GEOGRAPHY data to SQL Server no longer produces wrong values.
(Fix) Reading GEOMETRY data from SQL Server no longer fails to read a single point with Z.
ADO.NET dataport supports UUID and CHARVAR (ANSI text) values natively, without conversions.
ADO.NET dataport supports GEOMETRY and GEOGRAPHY values for SQL Server connections.
ADO.NET dataport supports SDO_GEOMETRY values for Oracle connections, with conversion through WKB.
(Fix) ADO.NET dataport no longer sometimes fails when tracking progress for long operations.
(Fix) ADO.NET dataport no longer sometimes re-runs a compiled command in case the first run fails.
(Fix) Oracle dataport correctly reads and writes NUMERIC values.
(Fix) PostgreSQL dataport forces datetime style to ISO format. (Before the fix, reading or writing datetime values from databases which use a non-ISO format by default could fail.)
SQLite dataport forces datatime values to ISO strings.
OLEDB dataport supports LINK table type used by Access for tables linked from foreign data sources.
Copying and pasting components converts maps to new storage format (post-Radian).
Copying and pasting components no longer stops if a table refuses to paste (eg, because the target data source does not support fields of the desired type and the table has no other fields) and moves on to paste other components.
Copying and pasting components adjusts references to components in maps and layouts.
Copying and pasting components adjusts references to components across data sources, if pasted into the same instance of Manifold. (Example: open a new MAP file, add a data source for Bing Maps, expand the data source for Bing Maps, copy the image from Bing Maps into the MAP file - the system will automatically adjust the new image to refer to the table inside the Bing Maps data source.)
Copying and pasting drawings to SQL Server and similar databases preserves the original bounding box of the spatial index, if it exists, or sets it to the bounding box of the data set.
Copying and pasting drawings to SQL Server and similar databases preserves the original SRID of the spatial index, if it exists.
Opening MAP files created by Manifold 8 migrates layout items for components and text labels.
(Fix) Triangulating an area no longer sometimes fails (the circumstances are rare).
Parsing WKT supports EMPTY geometry.
(Fix) Parsing WKT no longer fails to skip whitespace other than space (hex 0x20).
(Fix) Attempting to import data from a MAP file no longer sometimes fails if the MAP file contains components copied and pasted from linked data sources.
(Fix) Reading data from a CSV file no longer sometimes crashes due to a buffer overrun. (The required input was pretty complicated.)
Reading data from a CSV file better autodetects list separator, decimal separator and quote characters. (We fixed a number of cases where the autodetection could be fooled by having the first lines contain something like "a;b;c;d;e",f - this was making the dataport lean towards setting list separator to ';' rather than ','.)
Exporting an image to an ERDAS IMG file writes intermediate levels into an RRD.
Exporting an image to a TIFF file writes intermediate levels into an RRD. Reading data from a TIFF file automatically uses intermediate levels in an RRD.
(Fix) Migrating an image linked from a JPEG2000 file from a MAP file or an Enterprise storage created by 8 no longer fails to create a replacement link.
GPKG tables report total number of records to the Component pane.
Reading a SHP file supports reading files higher 2 GB (the format allows going up to 4 GB, but many software packages stop working sooner).
Exporting a drawing to a SHP file automatically starts a new SHP file if the amount of exported data goes past 2 GB.
End of list.
The focus for the next build is legends. However, we will merge at least a couple more things for styles that we have been working on: curved labels, line arrows and some others.