9.0.168.3

Here is our next build. The main focus was styles.

manifold-9.0.168.3-x64.zip

SHA256: 2404d4584c908d516c8ec0c9c6ca8e7865075f5fec2a67bfd0fb6f4398924468

manifold-viewer-9.0.168.3-x64.zip

SHA256: 5fb853a3b107c002701eae52b9abbee9b0259bd5cbb5dd3b9fc44afaf5430bbb

Changes

Color, font and style samples in all controls in dialogs and panes use the current rendering engine specified in options. (Previously, most of the controls were using the basic rendering engine = reduced graphics.)

The Style pane for drawings includes new style pickers for areas, lines and points, which allow setting or editing all parameters for a style simultaneously (colors, size, symbol, rotation if applicable).

The Style pane for labels includes a new style picker for labels, which allow setting or editing all parameters for a style simultaneously (colors, size, font, symbol).

Editing just the symbol for areas, lines, points or labels using a dialog hides controls for colors and similar parameters near the preview.

Picking a new value for a color, size, rotation, symbol or a full style uses a new dropdown window with choices arranged as a grid. The choices can be scrolled using the mouse wheel (we will likely add a scrollbar as well).

The dropdown windows for picking size or rotation allow entering the desired value directly at the bottom of the window.

The dropdown windows for picking color or full style allow switching between grid view (each row contains multiple choices) and list view (each row contains a single choice and shows its name).

The dropdown windows for picking color or full style allow filtering choices by name (eg, type 'green' into the filter box in the dropdown window for color).

The dropdown window for picking color includes the new 'Color Picker...' button that picks color from an arbitrary location on a screen. Clicking the button paints the entire screen with a light shade of white and changes the cursor to an eyedropper to indicate that clicking on a screen location will pick its color instead of working normally. Pressing Escape cancels picking.

The size of the text in font samples is increased from 8 pt to 10, to make fonts easier to distinguish.

The dropdown window for picking color includes many new colors. Colors are separated into groups, formerly used colors are in the first group. Groups are highlighted using alternating shades of gray.

The dropdown window for picking full style definitions for areas, lines, points and labels includes many new styles.

Editing a label style allows overriding colors used for label icon.

Editing background color in the Layers pane uses the new dropdown window for picking color.

There are several new symbols for points with inserts. Insert color is set to coincide with stroke color by default, and can be overridden.

Format picker controls use flat borders. Format picker controls in Record and Style panes no longer reserve space for the icon on the right and use the entire control area to paint the format sample. Format picker controls and template parameter picker controls use a darker shade of gray (the one used by the system controls on Windows 10) to better stand out as controls that can be clicked into.

(Fix) The default line size used by the Record pane is fixed to be 1, not 0.

Also

Web dataports allow specifying user agent string. By default, user agent string is set to 'Mozilla/5.0 Manifold/9.0'. Having a non-empty user agent string allows working with servers that require it - some US government servers, for example, require it for internal statistics / bug reporting.

ERDAS IMG dataport allows exporting raster data.

ERDAS IMG dataport automatically creates RRD pyramids when exporting raster data.

(Fix) Importing data from GeoTIFF correctly applies unit scale to coordinate system offsets.

(Fix) Exporting data as GeoJSON correctly quotes string values.

Exporting data as GeoJSON exports xN values as JSON arrays.

Web geocoding dataports use {...} syntax for URL parameters, similarly to web image dataports.

Web geocoding dataports that support both direct and reverse geocoding are split into two different dataport subtypes to allow customizing URLs for both geocoding methods. (Previously, the user could only access the URL for direct geocoding, and could not adjust parameters - like input language - for reverse geocoding.)

End of list.

The big picture: we think we are mostly done with styles, at least in structure. We do have a number of things we want to add - new styles, new symbol mechanics (particularly for lines and labels), several useful additions and refinements for the UI - but we can mostly add them along the way. So in the next builds we will perhaps be moving on to vector editing and to things like legends.

Tell us what you think, though. If you see any glaring holes or useful improvements to the current style system, we're absolutely ready to add or change things.

(I'll also do a forum sweep tomorrow to comment / follow up where it makes sense.)

There's some nice changes in there and some really powerful control over certain things. I still feel like you guys are missing the boat by not making the style pane show a full preview of themed layers. There would be room in the style pane if you remove the desire see at a glance styling for points, lines, an areas all at once for a layer. Very rarely do I ever have those all in one layer and even if I did, I'd get more out of a full preview.

Okay I've said my peace on that :-) Here's a list of other thoughts in order of importance.

1) Line labels absolutely need to follow curvy lines. Can't make maps without decent labeling.

2) Would really really like to be able to "pad" a line on either left or right not just underneath.

3) Need to be able to save our own styles and put them into easily accessed groups. I would much rather have that any preset styles that will go mostly unused by me and require more time scrolling or filtering through.

4) The current color grid is an unhelpful menagerie of colors. Can we get more order and control? Color brewer accent palettes are good and so are the palettes like spectrum and altitude in mfd 8. I'd really like to have my own set of colors that I can choose from and know how they will look coming off my printer. If I had this control, I'd set up a group of colors that work well with different backgrounds as well like aerials, USGS topo, favorite hillshades, etc.

Mike said,

4) The current color grid is an unhelpful menagerie of colors. Can we get more order and control? Color brewer accent palettes are good and so are the palettes like spectrum and altitude in mfd 8. I'd really like to have my own set of colors that I can choose from and know how they will look coming off my printer. If I had this control, I'd set up a group of colors that work well with different backgrounds as well like aerials, USGS topo, favorite hillshades, etc.

The M8 color groups like Spectrum and Altitude are still there in M9 and demonstrated in the videos on style. The interface is slightly different but certainly recognizable once you're in it.

I never understood the grid of random colors in M8 and am a little surprised to see it in M9. Is there a grand theory in computer graphics as to why that makes a good way to pick colors? I would seriously like to know more about it if there was. But if you don't like that, click the More... button below the grid. That takes you to a color finder which I have used very successfully in Manifold and other graphics applications. For me that solves the problem of order without confusion, but not for fine color control. If I were to wish for an improvement to that GUI, it would be to activate the up, down, left, right buttons, with and without the Ctrl or Alt modifier, when inside the color rainbow box (or the slider on the right) to make small changes to the colors and shades.

As to how it looks coming off the printer, I just got a used HP 800 plotter to replace the really used 500 model. The colors coming off the 800 seem to match the screen better than any I've had beforehand. We also have a Canon color laser which darkens the colors. Printing anything with a Google Earth aerial requires post processing. For that I use my standby image viewer, Irfanview, to change gamma from 1 to 2 and contrast from 0 to about 50. That makes a presentable aerial image from either plotter or printer. I'm certainly open to other ways of fixing colors.

I really like the idea of saving styles for future use and reference. Perhaps there could be a Save Style button in the style design dialog window. Pressing that button would open a dialog to name the style and save it to the list of styles already featured.

I never understood the grid of random colors in M8 and am a little surprised to see it in M9. Is there a grand theory in computer graphics as to why that makes a good way to pick colors?

That's just a consequence of sorting colors by name. There will be a button that allows sort order by associative hue (like PhotoShop swatches) or by names. Don't laugh at the "name" idea because names for colors are often required standards, used as standards for web pages and so on. There was a big conflict in years past when Pantone introduced names for colors, as an alternative to PMS numbers. Why did they do that? Because clients of designers thought in names and not colors and it was easier for designers to communicate with phrases like "Do you want the Burnt Umber or the Sienna?"

Regarding palettes, I think the idea is to provide a line of colors in the color grid as might be generated for 12 intervals of a particular Color Brewer palette or other palette.

The general plan for the color picker grid is to allow more than the current collection of Basic, Standard (a neutral synonym for ESRI) and Web (the standard set of named web colors). For example, Pantone names, Pantone PMS numbers and so on. No reason there could not be a section for Palettes, where each line is a sample of colors from that palette, or a favorites collection anyone might care to create.

I'd like to make a vote of thanks for the work that has gone into the colour infrastructure in 168.3.

I say this as an anomalous trichromat (nothing interesting, in my case a red-green colourblind person, the most common type, though of course "colourblind" is just as inaccurate a term as if I called myself blind rather than merely shortsighted) who nevertheless needs to work with colour. I appreciate all the structural support I can get, and this build goes a very long way in giving it.

Much better than previous builds, much better than Manifold 8. That is judging by what I can (correctly) achieve with colour in a short time, and that's what matters most to me.

Is there room for improvement? Sure. I wholeheartedly agree with David's comment quoted by Dimitri above. The default colour well is a visual headache. The colours are crying out for some perceptible colour order, so I was very happy to read Dimitri's comment (exactly on point) that

There will be a button that allows sort order by associative hue (like PhotoShop swatches) or by names.

I agree that we need that.

I very much like being able to choose between a matrix of swatches and a list of swatch + name, even though the names (which I gather are external standards) are not in themselves terribly illuminating in every case.

For the list + swatch display, I would like to suggest two changes. First, widen the swatch into a rectangle. There is no reason to restrict it to a square here (as there is in the matrix display), and there is menu space going unused. A wider swatch is easier to judge--especially, but not only, for those who are colour deficient.

The second thing is that I would really appreciate a column beside the name, giving one or more of the following: decimal RGB values, a #hex RGB string, plus possibly HSB or HSL (I'm not specially fussed between those two). Ideally the readout mode would be a right-click option on the column header, but that's not crucial. I don't think you need to add CMYK as well. (In fact that seems undesirable, since there would have to be an underlying colour space for translation, a complication best left to other software. The same may technically apply to RGB <-> HSB/HSL translations, but I think it's OK to fudge that slightly by using an implicit sRGB or system-defined RGB colour space.) This header, as well as the colour name, would ideally be available for sorting colours within their groups (basic, standard, web...).

The full-screen colour picker is a great idea. How helpful is that! Especially for anyone who wants or needs to work with natural colours (notably from photography). Two things I would suggest here too. First, the white wash makes sense, but is problematic in the sense that we get to pick a colour that we can't (now) see! (Because it has the wash applied.) However, there must be some indication, beside the colour picker cursor. The best alternative I can think of is a standard "checkerboard" pattern, widely used to denote transparency, laid over the full screen. Half the squares in the checkboard would have a white wash (as the whole screen does now), while the other half would be simply transparent, showing actual colour. This would not be perfect, if the exact pixel we wanted happened to be in a white-washed square; but half of the pixels would not be; and in both cases it would feel and prove better, at least in my opinion. Perhaps there is a better third option.

Oh, and an RGB/#hex tooltip readout for the colour picker cursor would be very nice to have.

Anyway, this was mainly not about further suggestions, but about thanks for something so easy to use. Please don't change it too much, because it's really good.

I can see some value in naming the colors, but you have to stop somewhere. For example check the attached PANTONE colors. They have four different names for colors which I might use interchangeably. I can perceive the differences in the colors, but I have no particular preference for one over another. But my wife would

Attachments:
PANTONE shades of blue.jpg

Thanks for the notes! We agree with all 4 items and are planning to do them all.

Regarding the first para - could you clarify what you think we could do better in the Style pane? We get that a drawing frequently contains just points or just lines or just areas, so some of the buttons could perhaps be hidden (eg, by user's choice) and this would free some space. But what do you want to show in that space? Thematic formatting? We do not show thematic formatting before you click on a button that has it, because there might be multiple types of thematic formatting applied (colors follow field X, sizes follow field Y or field X but with different breaks) and having controls for all of them on the screen simultaneously would be too much. But maybe we could design the UI to show a single type of thematic formatting and switch between these types easily. That way if you only have one type of thematic formatting (the usual case), you'd see it right away.

Yes, I’m thinking a tab of some sort to switch between points, lines, or areas to make room for thematic formatting and display it as it will appear (if desired) in the legend. Let’s try an example of road types. I typically would have all the road info in one layer and use a one or more columns to display road type. It would likely have different line type, colors, and sizes. I just want each road type to be shown in the legend with it’s name and not the info from the columns. Same example could apply to points of interest.

As you said it gets way more complicated when applying thematic formatting along with controlling column info. For example, point size indicates population and point color indicates population density. Nice we can do this but it is a less common need.

I hope there is a way to accommodate the more common and simpler needs in a user friendly way. Otherwise we have to zoom to various points on the map to see the look created by all the thematic formatting we applied. Alternatively, there will likely be some legend pane that also allows viewing the formatting and presumably further tweaking. Perhaps they style pane can be the layers legend pane as well. Of course it is much easier to shoot out ideas like this than it is to implement. Thanks for considering this.

After rereading your post, I think your explanation is right on and my post maybe confusing.

Also worked up this example that is helpful I think. There are times when it would be nice to be able to combine formatting as shown to make the styling and ultimately the legend more readable.

Attachments:
Capture.JPG

Yes, of course, we will allow you to combine formatting in legend groups like shown on your attached screen. (Legends are coming in a week or so.)

Nice improvements. The next good step would be in my opinion to be able to create/store/load custom styles and libraries of styles. (But I think you already have that in mind. That's why the "Standard" text next to the predefined styles exist, doesn't it? I mean there will be styles that will not be "standard"). In case you add this option I think it would be useful to be available to Manifold viewer too, just to be testable by more people.

I am confused with the line style window. When having a line with "background". there are 3 color pickers. The left-top one controls the central line color. The top-right controls the "background" line color. The left-bottom controls that too, until you use the top-right one. Then the top-right starts controling the back color, until you press its "default" button. I don't understand the purpose of 2 color pickers for background color. Also, after you use the top-right picker to control color, the style pane's 3rd button, that normally controls background color, starts doing nothing.

For convenience, all the color options start off by inheriting whatever is set for the main, top level, stroke and fill color buttons.

Depending on what is the style (Label Style has more combinations), there can be additional color settings for the various elements of the style. These start off by inheriting the main stroke and fill color but then some of the various elements allow setting an override for their own stroke and fill colors. With labels you can use up to six colors in a label given the various combinations.

For example, if you choose a point style that is a circle and then a surround effect that is the vector drop shadow, that surround effect can have its own fill color. The fill color starts off by inheriting whatever was the top level fill color, but you can change it if you like to an override color that will stay what it is regardless of how you change the top level stroke and fill colors. So, for example, you can set the vector drop shadow color to a dark gray and know it will stay that way while you tinker with the stroke and fill colors for the point symbol.

This build is also an experimental build, so there will continue to be improvements to help guide the flow of how colors are inherited and used. For example, the preview display will move to the top of the dialog, there will be many more basic vector styles added, etc.

...moving on to vector editing and to things like legends.

Great to hear legends are coming up soon. There was a discussion about desired features in legends in this thread http://www.georeference.org/forum/t143650.18 Are these suggestions under consideration or do we need to send them in as formal suggestions to sales?

My other priority wish list item is to be able to add a scale bar to Layouts. It would be nice if I could save scale bar characteristics. In M8 I would need to set up in each map or layout for a composite scale bar in kilometres (or metres for large scale maps). Having persistent settings for scale bars would be very useful.

A lower priority is having a North Arrow though I can work around that by pasting an image of a north arrow (an elaborate north arrow design taken from a historic ocean navigation map) into a layout. North arrow I can wait for.

It would be nice to have a scalebar that has some auto-adjust behavior. In M8 you have to specify the scale of the bar. I'd rather set the size of the scalebar and let M9 decide the scale.

(I hope I made my self clear)

http://www.mppng.nl/manifold/pointlabeler

To how many decimal places?

Well, you should be able to customize the displayed unit at least.

And Mfd8 shows a problem with a numeric scale, actually not an element of type scalebar but a text replacement:

This text is rounded in some mystic way and you don't see that it has been. There must be some sort of rounding due to the nature of floats. But that should only affect the fractal part behind the decimal delimiter in the chosen units. A common sprintf() with localization should do.

I am planing to send suggestions having to do with transformation templates, and I am posting firstly here in case I could improve those suggestions.

a) The "Restrict to selection" checkbox in the panel would be very useful to be replaced by the option to select the entities to be included in the transformation between "all", "selection", plus any saved selections that may exist. This could be done with a drop-down list like in M8.

The same option is useful also when applying transformations that need 2 drawings/images. Then the option to select the subset to take part in the transformation should be available for both overlay and target drawing.

b) In transformation panel, sometimes it make sense to have non only "Add Component" and "Update field", but also something like "Add to current component". For example when applying "Buffer" to some points we may want to keep both the points and the Areas created in the same drawing. Now we can only replace the points with their buffers or create an new component.

Also in cases like the Union Areas transformation there is only the "Add component" option, but sometimes the "Update field" (replaces many areas with one new, a very common case when ediding a drawing) or a (possible named) "Add to current component" option (keep old areas and add a new one in the same drawing), may be useful.

edit:Also in some cases the "add to current component" is what makes the most sense. For example in the "Compose rectangle" transformation. In this case usually with just add rectangles to current drawing, and we don't want them to replace existing entities, and we don't need a new component.

I like those suggestions.

I use buffers regularly. Most recently the county seat is codifying their zoning rules. They have to notify everyone within 200 feet of the defined zones about upcoming discussions at the town meetings. In M8 I select the zone properties in the working layer and create the buffer in my sketchpad layer. Then I select the new buffer area and use the Select Touching tool to grab the parcels and owners names from the working drawing. When I create the buffer I only need to put it into one sketchpad layer and not create new components for each buffer.

I also use Union Areas all day every day. I'm going through a project now to create subdivision parcels starting with all the parcels in the subdivision. My method is to create a union of all the parcels and close the road way gaps with a union of a temp area which encompasses the gaps. There are roughly 100 subdivision parcels to create. I would much rather update the original drawing than create 100 new drawings. Union Areas within a drawing is something I do multiple times a day even when not working on this project.

For Union Areas, you would perhaps want not "Add to Component", but rather "Update Component" - as in, add a new big object and delete old small objects, no?

Good stuff. Be sure to send that in.

Some early comments:

We don't know if we want to work with saved selections directly. Requiring the user to first set the current selection to the desired saved selection might seem like an extra step but this way we can equip the current selection with some useful things - ie, we can try to compute how many objects it contains and what types, to check which transforms will not make sense to even begin. This is mainly for the future though.

Restricting all involved components, not just the target one, to the selection, however, is a no-brainer. Yes, we should allow you to do that, good point.

Regarding "Add to Component", we aren't against that at all, but if we are going to have means to put tons of different stuff into the same component, we better provide some control over the Z order first.