9.0.168.7

manifold-9.0.168.7-x64.zip

SHA256: ca5c9064def7f46ac17e9aed43fe85aeda371760f3fcde0419a0f55ce6a16ccd

manifold-viewer-9.0.168.7-x64.zip

SHA256: cb7005c29e49154e0e19a1c7b026fe74755fed77c1130b2ffeabf9ffeb7fa77c

Styles

(Fix) Aligning label icon and label text correctly handles align angles just below 360 degrees (the last half-sector).

The preview in the style dialog automatically sets its background color to that of the component window.

The style dialog allows altering lists of bitmaps using a context menu (right-click a bitmap or a blank space in the grid). The context menu includes commands to add new bitmaps, delete all bitmaps, delete the clicked bitmap. The number of bitmaps in the grid is limited by 1024. Switching to a grid with bitmaps only starts adding new bitmaps if the grid is empty.

The style dialog caches bitmaps used for point and area styles for the duration of the session. If the style dialog is launched on a style that already uses a bitmap, that bitmap is shown in the separate readonly group named 'Current'.

(Fix) Bitmap point styles keep bitmap proportions for shadow and halo.

There are new point styles for basic shapes: diamond, pentagon, hexagon, octagon, plus variants with inserts. Diamond is different from rectangle in that rectangle fills the entire size x size box, while the corners of the diamond are on the circle of radius size.

There are new boxes for basic shapes: diamond, pentagon, hexagon, octagon.

Point styles with inserts are adjusted to allow insert color to be transparent. (Previously, setting insert color to be transparent was rendering insert using background color.)

Point styles with inserts allow specifying insert size (default is 30%) and insert type (default is auto = same as the main shape, other choices are to fix the insert to use a different shape = circle / rectangle / rectangle rd / triangle / diamond / pentagon / hexagon / octagon).

There are new point styles for basic shapes with dividers splitting the shape into two parts. One of the parts is filled using background color. The other part is filled using foreground color by default and the color can be overridden. All basic shapes use three types of dividers: diagonal, horizontal, vertical.

There are new point styles for flags with dividers.

Reducing width of rounded rectangle shapes converts circle arcs in corners into ellipse arcs.

There are new point styles for arrows: arrow triangle, arrow wing, and several others.

The style dialog for lines allows specifying begin cap and end cap. The caps are applied to each line branch. Available cap styles include basic point shapes (centered on the begin / end coordinate) as well as arrows (the tip ends on the begin / end coordinate). Placing caps automatically adjusts line metric near the begin / end coordinates to produce a correct arrow direction (this is different from, say, Manifold 8, which could take a mostly horizontal line and produce a vertical arrow because at the very end the line changed its direction and walked down for a couple of pixels). If the line is too short, caps are not drawn.

There are new line styles for repeats for basic shapes: circle, rectangle, rectangle rd, triangle, diamond, pentagon, hexagon, octagon. Repeats are specified as a pattern of <size>, <space>, ..., similar to the pattern used for line dashes. A negative size rotates relevant shapes 180 degrees. If the repeat pattern is empty, the style assumes '300%,300%', which is a sequence of 300% shapes with 300% spaces. There is an option to turn the base line on or off.

Left / right lines are oriented to proceed in the same direction as the line whenever possible. (This synchronizes repeats on left / right lines to start at the same logical position on the line and makes the orientation of repeats on left / right lines way more predictable.)

Unicode

The query engine supports new options for ordering criteria on text fields (used in CREATE TABLE / ALTER TABLE as well as in ORDER):

• KANATYPE / NOKANATYPE - use or ignore kana type for Asian languages, default is KANATYPE (two instances of the same character in, say, hiragana and katakana, are considered to be different),
• WIDTH / NOWIDTH - use or ignore character widths for Asian languages, default is WIDTH (two instances of the same character which only vary in width are considered to be different),
• WORDSORT / NOWORDSORT - use or ignore space between words, default is NOWORDSORT (space between words matters).

Dataports for databases expose all text fields as NVARCHAR (Unicode) even if they are stored as VARCHAR. Attempting to create a VARCHAR field will create it as VARCHAR on the database, but the field will look as NVARCHAR in Manifold.

(The intent here is to preserve data because what VARCHAR means varies between data sources and converting between different meanings frequently loses data. Example: in Manifold VARCHAR means 'characters in the currently active codepage, whatever it is', and on databases VARCHAR usually means 'characters in the codepage associated with the field / table / database'. If we connect to a database, we can ask it to return data as VARCHAR, and it might return data in a German codepage. If we then try to use that data as VARCHAR in Manifold, on an English system, the characters will be interpreted wrongly - this affects both display as well as comparisons and orderings. In Manifold 8, we used to allow setting a codepage for the field. However the end result was always just to convert the data in all codepages different from the default one to Unicode and handle data as Unicode - so we went one step further and moved the conversion to be as close to the data as possible.)

SQL Server indexes on text fields honor field collates.

(Previously, all database dataports were assuming that indexes on text fields sort values using binary order plus / minus case. This works reasonably well for field values with English-only characters, but starts breaking when field values start having non-English characters and when the query engine starts offloading searches to the database - which we started doing more aggressively lately. We are going to go through all database dataports and make sure that all indexes on text fields that we recognize and report in the schema work without any limitations on what characters the text values may contain.)

Other

(Fix) CASE NULL WHEN ... ELSE ... END correctly goes into ELSE. (Was previously returning NULL.)

(Fix) Exporting a drawing to SHP no longer sometimes writes incorrect record lengths making it hard to read any record after the first (this was a regression in the previous build, apologies).

Exporting a drawing to SHP writes points with a single coordinate and points with multiple coordinates into separate files.

(Very early on we were reducing multipoints to points, throwing the extra coordinates away. This was losing data and we wanted to fix it. We tried multiple different things, from just writing multipoints into the SHP for points even though the SHP spec requires all shapes in the file to have the same type, to, in the last cutting edge build, marking all points as multipoints. All of those solutions were producing issues in third-party software, including in ESRI products. So we have gradually came to just separating points and multipoints into different files. This does avoid all issues with third-party software that cannot handle multipoints that can realistically be avoided - if a particular product cannot handle multipoints, the user will not be able to work with them, but he will be able to work with the rest of the objects.)

There is a new dataport for ICO files (also loads CUR files), useful for loading bitmaps for styles. If a file contains multiple images, the dataport loads them all (and the style dialog chooses the biggest image with the highest number of colors).

End of list.

We are going to take a couple of days off for the holidays and then we will be back with more builds.

Happy New Year!

I just want to say, there is a staggering amount of new style stuff in here. There is a lot to unpack, but once you get your head around it, it goes very fast.

There should be some new, preliminary topics in the user manual very soon, as early as tomorrow. In the mean time, you can do things like this, a very simple use of symbols at the head of a line (an arrow) and at the tail (a circle).

Given the ability to use bitmap symbology (lots of websites to generate free pattern fills...), plus all the new standard stuff and variations, the amount of different symbology seems infinite.

Attachments:
lines.jpg

A collection of patterns used (style overrides) for area fills in a map of Mexico. You can, of course, use more cartographic fills. This just shows the extremely wide range of what is possible. Click on the image to see it full size.

Attachments:
mexico_patterns.png

I would nearly wear that shirt.

A very significant problem that has arisen is that the wealth of graphics effects possible are addictive. You can tinker endlessly. It is easy to sit down for a few minutes in the early evening to play, and then discover it is suddenly near midnight.

Quite a few of the seamless tiling bitmap image patterns, by the way, were generated using the patterncooler.com web site.

A couple of style examples:

Enjoy.

Attachments:
style-samples.png

What strikes me most here is the beautiful way, in the "bastide" example, lower right, that the corners of the area border are ever-so-slightly smoothed, barely more than anti-aliased (I think still sub-pixel).

This seems also to show in the way discrete style elements flow around the vertices.

Both look perfectly judged. (It must have been a heap of work to get this right for arbitrary cases, more than a handful.)

Yes. It's very easy to create, as well. Below is the Line style dialog. Click the Left tab, check the Left box to turn on the effect, choose the symbol (if you want a repeating symbol), click the stroke color to red and you're done.

The second illustration, below, shows how you can enter a line that modifies how the repeating shapes appear on the "Left" effect. The 10 says to make the shape 10 points in size, the 20 says to put a space of 20 points in between shapes. You can concatenate such pairs if you want to have various sequences of sizes and spaces. As you put it earlier (very good phrase), it is a "self similar" approach to specifying repeating sequences such as dash, space, etc.

Attachments:
left_line.png
left_line2.png

It must have been a heap of work

Forgot to mention... there are endless small details like that. For example, in the illustration of lines I posted with Left/Right effects plus an arrowhead plus a circle tail, note that the Left and Right effects do not overrun the arrowhead. That's something extra Engineering did, to clip such effects depending on the shape of the arrow, size, etc.

There's also optimization so that if you have a long line that takes a short right turn for a small segment. Release 8 aligned the arrowhead with that last tiny segment, so you could have what appeared to be a long line with an arrowhead turned at right angle (the final segment being too small to see). 9 optimizes that away and puts the arrowhead as you expect it, along the bearing for the line that the eye sees.

... time for a beer. :-)

This is all extremely cool. Just curious if you have added a point symbol that is an arrow that rotates around the point at the bottom of the arrow (the end of the shaft) instead of the middle? This seemingly small thing would be a big deal in the wireless industries.

A pie slice shape that rotated around the pointy (or pointiest) bit, whose width could vary based on a variable angle, would also be helpful.

You can do both of the above today, using total style and simultaneously varying Angle/offset and rotation.

Another way is to use a bit map where the center of the bitmap is at the bottom of the arrow shape and not in the middle of the shape.

Here is an example, from one of the upcoming topics. The clocks are formed in two layers. The lower, Cities 2, layer puts a bitmap image symbol of a clock face at the location each city. The upper, Cities, layer is a thematic format of each city point using a "Time" field that has a value from 1 to 12 for each city.

The Cities layer point style uses the Standard triangle symbol with a Width of 30%, so it becomes a vertically stretched out triangle. The offset for the Move parameter is 50% for all of the intervals, but for each interval from 1 to 12 the Rotation and the Angle for the Move parameter are the appropriate angle in degrees. For one o'clock, for example, both the Rotation and the Angle are 30.

The effect is not quite perfect because the lower layer clock face bitmap image is not exactly round and it is not exactly centered in the bitmap. But it's close.

You could, of course, use whatever symbology you wanted instead of the Standard collection triangle. For example, you could use an arrow with a shaft, adjusting the Stroke and Width as you like. You could use a photorealistic bitmap image of a human hand with a pointing finger for the hour hand of a clock and position it using Move.

Attachments:
clocks.png

Clocks with hands, using a bitmap image for the Cities points. The image used for the hand is almost half blank, transparent pixels so that the center of the image falls just slightly back of the index finger's first knuckle. That allows the effect to be done using a thematic format exclusively for rotation.

Attachments:
clock_hands.png

Some existing topics have been updated and some new topics have appeared in today's refresh of the user documentation. See the Style Topics book within the Style / Formatting chapter.

Great.

Quick suggestion:

Currently there is a Changes and Additions section at the top of the hierarchy. It deals with changes to the software, and is always useful.

How about a section just under or over that mentioning recent changes to the documentation itself? It wouldn't need to be as systematic as the Changes and Additions section (or as long). You could call it e.g. What's New Here.

Then the great new stuff would be more widely read!

The german ui file for v 9.0.168.7

Attachments:
ui.de.txt

Shutdown adjusts priorities: Do we really want to go back to where we came from?

Thanks Klaus!

That's just in time, as I note the new Style: Lines and Style: Points and Style: Bitmap Symbols topics use Germany. :-)

Attachments:
eg_style_lines01_01.png

Status update:

We are planning to issue the next cutting edge build either late this week or very early next week.

One more update:

We are planning to issue the build in the very beginning of the next week, likely on Monday, 21-Jan. The build is going to be an out-of-band build where we incorporate a long-awaited series of changes in an area unrelated to the main focus of the current build sequence (vector styles / editing + layouts). We took a detour from the original plans for the build due to a big set of start-of-year cleanups and upgrades to components.