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.

Databases

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

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.

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

There's an enormous amount of new material to unpack in all that, very difficult to do without up-to-date documentation, examples and videos. There should be a quick video on using the new styles in the next day or two. Once you get your head around it, it goes very quickly and logically.

In the meantime, below is an example quickly tossed together. Whenever you get very many style options you can use those to create really elegant presentations, or, also, some spectacularly cluttered and ugly presentations. This is the latter, since I threw it together very quickly.

It shows how bitmaps can be used for point styles, how lines can use inner and outer elements for very complex line compositions, how areas can use bitmap fills controlled by thematic formatting (use very large style sizes when using the marble or stone bitmaps), and a mix of vector formatting, etc. Click the image to make it bigger.

The art images are part of a collection that might be used for an example of where artworks are located in Europe. They're .png images set in box elements with a combination of halos and shadows on the box, etc. YOu can see how this could be used with thumbnails for a real estate listings site, diagrams of factory or house plans at a site, or just cool 3D icons. I've attached some textures and starter bitmaps for anybody that wants to play around with these.

It's easy to find flags and many, many other bitmaps that can be used. 9 can use any of the image formats it can normally import (very many).

Put these where you can find them, and then when you set the symbol for a point, you can choose "Images" in the drop down menu in the Style dialog instead of "Standard" or "Glyphs" or whatever, and navigate to where you have the images.

It's a big step forward, for sure. But for all that, it's an early step in a cutting edge build that, as usual, opens the door to many, many ideas and reactions from intrepid cutting edge users that will drive many possibilities for adding to the wishlist for development. :-)

The intent for this build was to deliver in a group many of the style advancements that were in progress in a form that is both usable and reasonably close to what is expected to be the production user interface. But within that user interface is plenty of room, and plenty of need for, various refinements that will greatly assist workflow.

An example, using bitmaps as point styles: To use a bitmap as a point style you click on the symbol button for points (or the total style button) and drill down through More... in the drop down menu to the style dialog. There you see the now-familiar initial array of "Standard" vector symbols for points, but now in the drop down menu from the little symbol button in addition to choices of Glyphs, Brands, Fonts and a short list of popular fonts like Wingdings you also have an Image choice.

Choose that and an Import dialog opens so you can browse to a folder that contains images in any raster format 9 can read. By the way, if you see a Windows "Details" list presentation in that Import dialog, you can right click and choose View - Large icons to get a Windows visual preview of the content of each. Ctrl-A to choose All of them if you want, and press Import.

That now adds a whole bunch of images to the style dialog's array, allowing you to click one and see it in the preview pane. You can then click on various options to position it relative to the tie point, use a shadow or halo, add a box element around it (which in turn can have its own stroke and fill colors, shadow and halo and colors, etc). Choose what you want, press OK, and you have the symbol. Back in the uppermost Style pane you can set rotation, size and so on.

The image you chose is automatically imported into the JSON string for the style, stored there in compressed form as a 128 x 128 (if it started out square) rendering that thereafter is scaled as the size parameter says. That's convenient because you can start with relatively large images, up to 1024 x 1024, which are huge sizes to work with for something that will end up as point symbols, yet because they get scaled down to 128 x 128 compressed bitmaps that keeps the size of projects smaller and results (through optimization) with very small PDFs. Use the same image a thousand times in a PDF yet it is only stored once in the PDF.

[One reason these new facilities took a while to merge is that they all, of course, must work in PDF and in all the other things Manifold does, such as, for example, being able to save styles into GPKG storage like one of the example topics does, etc.]

OK... so suppose you want to change the image? Click on the Symbol button and drill down into the dialog and you'll see just the one image in the array that you're using. You'll have to choose the Image choice and Ctrl A and re-import the folder. That's an example of a small improvement that should get gone that will help a lot: once a group of images have been imported, they should be remembered, at least for the session, so that you more quickly can pick a different symbol as part of the tinker time involved in styling a display.

The compression, storage and rendering of bitmaps within styles works remarkably well. It can produce a startling effect in terms of clarity and precision, well beyond what is taken for granted with 8 or other "classic" GIS. That leads to many more ideas. For example, the idea of decoupling the use of bitmaps within a project (because they are stored in the project) without having to drag along a folder with a given path that breaks everything if it is forgotten is very useful. It's so useful that it is tempting to think of tables in the project that store very many bitmaps for possible use as symbols. That's easy to do and could be done now manually, but, with some thought and input on how most conveniently and extensibly it should be done would be a great addition.

If you play with the samples in the files I attached you can see that very crude edits to cut out interesting parts of artwork, leaving rather jagged transitions from visible pixels to invisible, still works astonishingly well. That's because the ability to work with a very large bitmap that is automatically scaled/consumed as part of the import process allows a slacker approach to image preparation that still yields good results. It helps to increase contrast a lot on the bigger images, and it is clear that a slightly more attentive approach (as often is the case) in preparing slightly smaller versions of very large graphics destined for use as relatively small bitmap symbols can yield better quality.

But still, as can be seen, the quick and dirty approach works remarkably well. Start with a 3k x 2k image, hack at it for five minutes in a graphics editor to cut out what you want in a crude way, reduce it to 500 x 500 or 1000 x 1000 or whatever and you've created a bitmap image that can be used as a symbol. Frolov, for example, (the guy in the beret) looks fine as a symbol even though the original 500 x 500 is very crude, way too contrasty and otherwise awful. One tip for choosing fill colors for box elements: you can use the eyedropper tool to pick a color that appears in the bitmap and then use More... to adjust it lighter/darker so you get a compatible tone, if that's what you want.

For very fine, graphics-arts professional or talented amateur work, rendering 3D symbols or preparing artwork that takes advantage of anti-aliasing between visible and invisible pixels for cutouts can produce absolutely eye-popping results. The anti-aliasing and transitions between visible and invisible scale very well in the technology used to store bitmaps for styles by 9. I like the idea of adjusting drop shadows so they work on visible pixels, not just on the bounding box. That will enable more convenient use of shadows, for things like the strawberry bitmap shown in the example above.

As we all get more experienced at taking advantage of what is possible, no doubt there will be many more tips to share with each other, suggestions for small refinements that add lots of workflow convenience, and, hopefully, more and more collections of useful stuff to share with each other as well. :-)

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.

The very welcome Line styles aware of 'left' and 'right' side are of limited use as long as the direction of a line is not a conservative property of the line, i.e. as long as the direction is not preserved over transforms like Normalize, Split, Clip, Segmentation.

It's clear that merging transforms need manual rework of the result.

I don't know why technically the order of points in a line is "normalized" by many transforms. If this has an impact on display speed or ? it might be interesting to integrate a keep-direction property in the component accepting loss of performance. In this case merging lines could refuse to merge revers lines and follow an unambiguous path in a net of directed lines.

As I think this would imply an addition to the data structure of drawings or an additional object type vector it would be priority task to implement such a feature and probably has already been thought about. One-way lines is an old feature request.

I did a simple test. I drew 5 lines and I used the new "Use left" option to visually distinguish sizes. The left size line is the blue. (pic1)

Then I applied the Normalize transformation with 0 tolerance and the 2 of the 5 lines direction changed. (pic2)

Line direction matters in many cases, so preserving is important. If it changed unpredictably several and important errors in the analysis results may occur.

Did the same thing happen in M8 too? Some years ago I had a city road network as lines (where directions mattered a lot). I did several transformations and at some point I realized that some lines directions was wrong. I coulnd't figure out what went wrong. I had to manually check one by one all lines' direction.

The very welcome Line styles aware of 'left' and 'right' side are of limited use as long as the direction of a line is not a conservative property of the line, i.e. as long as the direction is not preserved over transforms like Normalize, Split, Clip, Segmentation.

We agree with this.

We are planning to adjust Normalize / Clip / Split and other geometry functions to preserve the direction of lines whenever possible (it is not always possible, see image) in the future, that's part of our "geometry" list.

Note for the image above: the branches touch, normalizing the area joins two branches into a single branch and this necessarily loses the direction of one of the branches.

The recent additions to styles are really powerful and also have great potential for more. What is missing is in my opinion is the following:

Areas:

Area patterns with point symbols. You can partially do this now by using an image. But you cannot adjust the spacing between the images and their size. When adjusting the size property of the area, the whole images size changes. So currently you cannot create for example dot-density maps, where the dots are all same sized and the space between them is what changes according to a field. IMO in the area style-symbol tab there there could be a 5th style with repeated symbols area pattern.

Inner/outer offset setting could be separate for inner and outer.

Border/Inner border/outer border: See bellow comments on line symbols.

Lines:

Zig-zag and wavy symbol styles. The properties could be customized by user by a way similar to that currently used for dashes customization.

Lines with arrows.

Consequent point symbols lines.

All the above could apply to area borders too.

Different settings for left/right offset.

Points: Nothing more.

Last, I minor rendering thing I noticed. When creating a line with left/right lines, sometimes the left or the right lines are extended a bit and they also turn a little. See image:

Area patterns with repeating symbols - we are adding them, but not as an additional tab and rather as built-in styles. There are two reasons why. First, because if repeating symbols are an additional tab, then inner / outer either cannot use repeating symbols or need additional tabs, this snowballs fast. Second, we'd like to be able to make styles with repeating symbols smart - have some ideas for the future. So, this is a trade-off.

Inner / outer offset and left / right offset are currently the same because computing offset shapes is expensive (well, relatively speaking) and having two different offsets would double the work. We have a couple of ideas on what we could do to improve the performance, then we might separate the offsets.

Zig-zag and wavy lines - coming.

Lines with arrows - coming.

Line styles with repeating symbols - coming, as built-in styles without a separate setting for symbols, similarly to areas.

We know what produces the effect of left / right offset lines on the attached screenshot (left / right not cut off sharply as they should) and will fix it.

Thanks for the video. Several really good things in there that didn't come to mind while I was tinkering with it. Agree that easily accessing all the bitmaps for choosing will help a lot. So would allowing us to save our custom styles and to easily choose from them.

Couldn't help notice you also seem challenged by the timing issue with click vs click+drag when drawing the line in the video. Hope that can be worked out better as it can be annoying.

Also, noticed the time it takes to move the cursor over to Update Record. The bigger the screen the more an issue that is. Perhaps add the option to use Ctrl Enter like when finishing a drawing object.

With the fancier style options, probably should bump up the size of vertices on vectors to make them more noticeable.

Perhaps add the option to use Ctrl Enter like when finishing a drawing object.

Ctrl-Enter is there already. I think I'd prefer a Ctrl-Click to finish editing. That way you don't have to take your hand off the mouse. There's no need to move the mouse a great distance as you can always right-click and choose Save Changes from the context menu.

On click vs. click+drag I've noticed that seems to depend on the mouse I'm using. With cheapo mice (the kind that give a click sound even when there is not yet a click all the way...) it's an issue, but with good quality mice I don't seem to run into it as much.

It *is* very convenient to be able to pan and zoom in the middle of editing, so I'd hate to lose that. I get the feeling that doing it a lot will just get muscle memory in place so it's not an issue.

Ctrl-Enter is there for drawings, not for the style or record pane. Moving and resizing panes helps as dchall8 said but why not add a keystroke option to apply the changes.

For drawings, as you said, Ctrl-Click would be better than Ctrl-Enter. Double click would be easier, so I suppose there is a reason that doesn't work well.

Panning while drawing is definitely good so yes let's not lose that. I think the problem is too much existing muscle memory :-) Perhaps the pan option when drawing only works if the drag is activated for a longer time frame like 1/2 a second. That might work since while drawing there usually isn't a need for tiny pan movements.

Double click is click followed by double click - that's both in how the operating system implements it and what the user guidelines say about how it should work (the principle of least surprise). So if we were to have double click end editing and do it in the way natural for how double clicks are generally supposed to work, we'd have to insert an extra coordinate at the location you double click - and that seems bad. Ctrl-click might work. There are a couple of other alternatives, but in general we hear you and others, and will make this easier and more intuitive.

Same for better distinguishing click from click+drag, we have some ideas regarding how to make that work better.

Either the pace of this video is faster or my brain couldn't process it in real time (= mind blowing). In any case, it is a video which can be easily stopped and backed up, so...good pace. Having watched the video I am seeing more in the png image posted above. It's the holiday season and we're getting much less traffic through the office leaving some time to play with M9. This is a well timed release.

'icon' = 'Icon' which is 'eingedeutscht' but isn't really german but translated as 'Symbol' - and we already use 'symbol'.

To 'Move' a point symbol controls the exact angle and distance of the insertion point of that symbol and so I translated it to the verb 'verrücken' in contrast to "Versatz" always used for 'offset' (without angle)

--

'use' ist such a short verb I couldn't find a short translation for. So all those label controls in the dialogs for 'use border', 'use left', 'use box', ... (DialogEditStyleCtlUse...) are too short to show the complete translation and should please become widened.

--

I guess I have an unchatchable lead in the endless possibilities to customize styles just by translation of the dialogs ;-)

'use' ist such a short verb I couldn't find a short translation for. So all those label controls in the dialogs for 'use border', 'use left', 'use box', ... (DialogEditStyleCtlUse...) are too short to show the complete translation and should please become widened.

Given the many new capabilities in Style there are extensive updates underway to the documentation. Two topics that provide a good overview of new style capabilities are below. These are for labels, but what they cover is helpful for point styles too and to some extent, line and area styles, for common features such as use of halos.