Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System 9.0.168.2
adamw


8,139 post(s)
#21-Sep-18 17:27

9.0.168.2

Here is our next build. Apologies for the long wait and several delays. The delays were mostly related to making sure what we write works well for PDF or for physical printers, does not become too slow on drivers substituted by remote desktop, etc. After all these weeks we think we are finally in good shape on all ends.

manifold-9.0.168.2-x64.zip

SHA256: 2090f7f6a98385f3f9795681695c7847511e20241fcc9592e0b6e689d8778d25

manifold-viewer-9.0.168.2-x64.zip

SHA256: f18c8d6ed0e2dc5d60a170408454182742ee8ce90989f7fcae7a5ac7873e80ba

adamw


8,139 post(s)
#21-Sep-18 17:28

The focus of this build is rendering vector data.

One thing about maps is that they have huge visual diversity. The number of different symbols, strokes, colors, etc, that people use for vector data in particular is staggering. It is rather obvious that however many preset styles for vector data we provide, there will always be a call for more. So, what we wanted to have for 9 is a way to specify how to display vector data that would be flexible and extensible.

With that:

  • we converted style strings from plain style names to JSON,
  • we added style parameters that the user can tune, changing the look of a style,
  • we split style data into logical blocks and allowed combining them independently within a style,

...and we also made sure it is fast, robust, works for both screens and printers, including PDF generation, as well as easy to use both interactively and programmatically.

Changes

Graphics engine choices in Options are renamed from Engine: Advanced, hardware acceleration allowed / Advanced / Basic to Graphics: Normal / Normal, no hardware acceleration / Reduced. (We think this better reflects the nature of each choice.)

Font definitions use JSON. Old font definitions are mapped to JSON seamlessly.

Fonts allow weights other than bold: light, semi-bold, ultra-bold, etc.

Fonts allow a new type of italic: oblique. (Currently this can only be set in the JSON string, the system font dialog does not show this option. We are planning to replace the system font dialog with a dialog of our own in the future.) Normal graphics only.

Fonts allow specifying stretch: normal, condensed, expanded, etc. (This also currently can only be set in the JSON string, not via the UI.) Normal graphics only.

Style definitions use JSON. Old style definitions are mapped to JSON seamlessly. (Old and new style definitions can be mixed freely as well. For example, if we open a pre-168.2 MAP file with thematic formatting for styles and change the style for one of the thematic choices in the style pane, the system will happily use the new JSON style for the edited choice and old style strings for all other choices.)

Style pickers for areas, lines, points, labels allow specifying a custom style using a dialog. The dialog allows specifying parameters for a style and displays a preview. The preview as well as all style choices in the dialog are rendered using the graphics engine specified in options (unlike format pickers in the Style and Record panes, which are currently always using reduced graphics - we will change this).

Editing a point style allows choosing styles from either a built-in list of vector shapes (Standard) or from a font. Instead of listing the names of installed fonts, the dialog provides a list of symbol fonts available on Windows systems (Wingdings, etc) and an option to specify a custom font. All parameters of a custom font are preserved (previously we were discarding all options like font weight and were only using the font name).

Point styles for vector shapes allow specifying stroke width. Stroke width as well as all other numeric parameters for distances can be set to either an absolute value in points (for example, '5') or a percentage of the size (for example, '100%'). The default value is 1 pt.

Line styles with dashes allow specifying dash length (default 300%), dash space (default 100%) and whether dashes should use round or flat caps (default flat). Normal graphics only.

Line styles allow specifying exterior rendered "below" the line. The only exterior option for lines is currently is a solid line which is as wide as the line size plus specified padding (default 3 pt). By default there is no exterior.

Default line size is changed from 0 (device-specific pixel) to 1 pt.

Area styles allow specifying border style (default solid) and border stroke width (default 1 pt). Border styles with dashes allow specifying dash length, dash space and dash caps, with same defaults as for lines.

Point styles allow specifying exterior. Exterior options are: circle, rectangle, rounded rectangle. Parameters: stroke width (default 1 pt) and padding (default 3 pt).

Point styles allow specifying exterior: shadow. Parameters: angle (default 135 degrees) and offset (default 3 pt). Rotating a point does not rotate the shadow (intentional).

Area styles support rotation for the fill pattern. The Style pane and the Record pane include controls to specify area rotation similarly to point rotation. Area patterns rendered from vector data continue to use antialiasing, etc. Normal graphics only.

Area styles allow specifying stroke width (default 1 pt).

Label styles are reworked into label exterior options, similar to points, and similarly parameterized.

Labels can display a point sign together with the text. The location of the sign is determined by the label style. (Currently the only option is to have the sign on the left, we are going to add more options.) The point sign can be either a built-in vector shape (with a parameter for stroke width) or a font character.

All styles allow overriding colors for the exterior. (For example, you can set the shadow for a blue-yellow symbol to be light gray, or you can set the border of a red-transparent area to be a darker shade of red.) All overridden colors can be set to be transparent.

Label styles allow specifying the size of the point sign (default 100%) and the space between the point sign and the text (default 3 pt).

Point styles for built-in vector shapes allow specifying width (default 100%, can only decrease).

Editing a style allows specifying colors, size and rotation for the preview.

There are multiple new styles for areas and points.

Also

Clip transform is renamed to Clip Individual, Clip All transform is renamed to Clip.

Parameter pickers in Select and Transform panes are made slightly less tall and cleaner, dropdown arrows on the right are removed.

Gravity and Kriging transforms allow interpolating data with Voronoi neighbors outside of the convex hull. Passing a zero for the number of neighbors (the default) restricts output to the convex hull, passing a negative value produces data outside of the convex hull.

Voronoi transforms use a single margin parameter instead of inflate X and inflate Y parameters. The margin is applied to the extent of the original data, not to the extent of the original data plus Voronoi vertices like before (this stops the result of Voronoi transforms from looking like a huge rect with all data in one of the corners - if preserving all Voronoi vertices is important, this can be achieved by pasing a huge margin). Passing a negative value for the margin sets it to 1% of maximum dimension of input data.

IMG dataport supports more variants of IMG / RRD.

End of list.

Dimitri

5,045 post(s)
#21-Sep-18 20:20

How to choose a symbol font:

Suppose we want to set symbology for points. Click on the point symbol button in the Style panel as usual, and then in the drop down menu choose Custom. The new Style dialog opens up.

The Standard set of point symbols are in the first section. In the upper right corner is a small button with a circle/square icon. Click that and it gives you a default list in the pull-down menu... choose Custom.

You can now choose a front. Everybody should have FontAwesome installed on their system (can download that from the product downloads page) - it's a great collection of symbols. ESRI users who have installed ArcExplorer (still a free download) with the fonts pack (still a free download) have all 33 of the ESRI symbol fonts as well. Choose the font desired and click OK.

You now have symbol fonts loaded in the upper panel. Click one of the symbols to choose it and it appears in the preview section. Click a star symbol, for example.

You can now customize that by clicking one of the external styles. ESRI calls these "halos" and Manifold might too. Click the circle in a circle and you'll see a circle appear around the star in the preview section. The stroke and fill colors for that halo can be set independently. Change stroke to 3 to make it fatter. Change padding to 6 to make the halo circle wider.

Press OK and then update record. Note that you can change the fore and back color independently. If you use a font symbol, those are all just one color, the foreground color (which maybe Manifold might start calling the stroke color, to distinguish it from the fill color, since nobody can ever figure out what is supposed to be foreground vs. background...). But some of the "standard" symbols are two color, which means given the two colors available in the halo you get four colors to use if you like. Many more standard symbols will be added, as well as many, many more standard patterns for areas, lines, etc., with means to create your own, etc.

I have about 40 symbol fonts on my computer, which make for hundreds of point symbols right now. You can use them in labels, too.

geozap89 post(s)
#22-Sep-18 07:45

"Line styles allow specifying exterior rendered "below" the line." A very useful option. I would like to see the following options too:

1. Option to have more that one lines "below", one bellow of the others. This allow styles like this in pic1. At least 3 or 4 lines I thing are needed.

2. Option for a style that allows 2 or more lines one next to the other like in pic2. There could be a blank space between those lines. (pic2b)

3. Option to have a line style consisting of sequential point symbols and/or normal lines (pic3)

I think those styles are basic for cartography and I am planing to send a suggestion for those, along with other suggestions I might think.

Attachments:
line styles 1.png

adamw


8,139 post(s)
#22-Sep-18 08:29

Thanks, this is exactly the feedback that we need!

rk
276 post(s)
#23-Sep-18 08:57

I have wanted directed or asymmetric line stlyes and arrowheads.

Image from M8 manual.

tjhb

8,280 post(s)
#22-Sep-18 23:49

Here's something I find confusing.

I have a drawing layer containing areas, and activate Contents > Style.

Looking at the controls for areas (the first row), there seems to be a conflict in their roles.

The third control governs fill style and stroke style.

Let's say I choose Custom... from this control, and specify a cross-hatch fill style in the top panel, stroke 1, and a dashed stroke style in the middle panel, blue colour, stroke 5, dash 300%, dash space 300%, round cap. I see the effect of these choices in the preview panel at the bottom. That's all good.

Now in the bottom panel of the same Custom control, beside the preview, I choose foreground and background colours, a scaling size of 15pt, and a rotation of 45°. Again, I can see the effect of these settings in the preview. I OK out of the dialog.

But those last four settings--foreground and background colour, scaling size, and rotation--seem to have no effect. The effective settings are instead governed by (duplicate?) controls in Contents > Style itself (the first, second, fourth and fifth controls).

If I now open the Custom... dialog a second time, the settings I made before in the bottom panel (foreground and background colour, scaling size, and rotation) are reset to their defaults.

What is the design intention here? Duplicating controls like this is (especially where one set has no effect) looks like a recipe for confusion.

(I suspect that the answer probably is that the Contents > Style pane itself is about to be replaced, at which point all Custom controls will be effective?)

geozap89 post(s)
#23-Sep-18 07:31

A maybe related problem with lines:

I have a line. From the contents panel I set the line width to 10pt and color to red. From the 3rd button of the lines row of buttons I select custom. I see on the bottom that the width is not set to 10, but to the default for this panel (8pt). Also the color is not set to red, but to the default black.

Next I select 20pt in the custom window and the the color to blue. The preview changes. I press OK and exit the custom window. But nothing changes on the line. It is still the 10pt black line it was before. So the custom window doesn't work in this case. Maybe, as tjhb writes, the contents panel will be changed in the future. I think all buttons should be removed and replaced by 3 (areas, lines, points) "set style" buttons, and then everything be controlled in a similar to the present "custom" window, including field driven formatting . (you can't set the properties of a custom styled vector to be automatically related to a field value). By the way, QGIS sets styles in such a way.

QGIS does also a great job on designing styles, as there is a lot of flexibility. For example line styles can be designed by the user by adding to the style various "simple lines" each with its width, dash style, offset from the axis,etc, or by adding lines consisting of repeated point symbols ("markers") (several options here too). Drawing order of the individual lines can be controlled by the user. I thing arcgis has also a similar style manager.

Dimitri

5,045 post(s)
#23-Sep-18 12:58

By the way, QGIS sets styles in such a way.

QGIS does also a great job on designing styles, as there is a lot of flexibility.

With respect, while I think there is plenty to be learned from every other GIS out there, including Q, the way Q does it has issues. To my taste, Q overweights a too-much-at-once approach, so doing simple things is not as quick as it should be.

Suppose you have a layer of points and you want to change the style from a round green dot to a square. In 9 that's a quick and immediate choice. In Q it is multi-level: First, you right-click on the layer and choose Styles near the bottom of the menu.

That pops open a menu-like dialog with a color triangle/wheel, and down at the bottom an Edit Symbol choice.

Choose Edit Symbol and you get a typically Q dialog with very many choices (some of which are weirdly out of place), including a fill color choice that when you click it provides a different way of choosing color, as shown above. To change the round dot you click on Simple Marker in the uppermost hierarchy pane and then in the bottom pane you can click on the square symbol. Press OK. Whew! That's a lot of clicking for what is done much more quickly in 9.

I prefer the 9 way of clicking the point symbol button and then clicking the square and you're done. With Q, changing a simple thing like a round circle to a square for a symbol requires drilling into too many levels, while for a very basic thing like changing a color there are two entirely different interfaces that occur in two adjacent dialogs.

I understand the desire to have an "all in one" dialog, but that that can push too much at people at one time. You need to have a quick and simple way to do common changes, like point size, with as few clicks as possible, and without exposing people to, say, bevel/miter/round join styles for strokes [a part of the Q dialog you encounter when changing point size].

The flexibility in Q is also implemented in a way that leads to very slow performance: Q can be wretchedly slow and full of errors when you start using the flexibility in styles. Consider the illustration below that shows points in Q 3.2 as imported from the OSM Boston PBF.

The default round point symbol has been changed to a cross, and the drop shadow effect has been chosen. Redisplay becomes impossibly slow, compared to the more or less tolerable display of default points (Q is slow with PDF to begin with... that's not the style system for default point style), and there are numerous errors (the shadow squares) that appear.

You get that with Q because different hands have wired up basically everything in the low level graphics kit Q uses, but they didn't coordinate all that within a unified design. The idea of stacking styles within the dialog in principle is perfectly OK, but it adds complexity for simple things and it leads to inadequate performance.

What 9 does internally can do all that too, but I think it is far more useful in day-to-day GIS work to have very quick and simple ways of doing common things at the top level, with more complicated variations lower in the UI dialog hierarchy, where experts can get at them but where people doing something simple and fast need not deal with kitchen-sink complexity.

Clearly, 9 can improve and expects to improve what is in this cutting edge build. For example, I'd like to see longer default lists of choices for things like point symbols when you first click on the point symbol button, and longer default lists of fonts, not just the Wingdings ones, before you need to click Custom to expand it yet further (probably should change that "Custom" prompt to "More..." as well).

That is where good feedback on what should be the top level quick access stuff is most important. It is easy to kitchen-sink people with too much in one dialog. The hard part is reducing it down to small sets of top level stuff, putting the more exotic, more rarely used features lower. ESRI, by the way, I think does a good job at that - much better than Q.

Attachments:
q01.png
q02.png
q03.png

geozap89 post(s)
#24-Sep-18 07:59

I don't mention QGIS to praise its vector rendering capabilities, or its general qualities as a software. Actually, QGIS rendering speed is clearly inferior to that of m8, not to mention m9. My purpose is to point to the advantages that modular design of vectors styles has, like it is done in QGIS and I think in arcgis too. At this point M9 seems to take a non-modular aproach to complex vector styles design.

For example, as it is described in the original adamws' post about the 168.2 version, "Line styles allow specifying exterior rendered "below" the line". So you have a line that has several properties like basic line color and dash pattern, an exterior for that line with some more properties. My opinion is that this way of definition of vector style is not the best possible, while modular design is better. In the above case instead of having a line and it's properties, it would be better to have 2 individual lines, each one with its' properties, drawn in an order that can be modified by the user. This way the user can design more complex and varied styles and the manifold programmer wouldn't have to predict every possible combination of properties a complex line style may have. Modular design of vector styles is the only way to have complex styles like the one in the QGIS style definition screenshot bellow.

I don't think many people would use a style like the above, but I want to make clear the flexibility modular design offers.

adamw


8,139 post(s)
#24-Sep-18 09:47

We agree being able to build a composite style out of an unlimited number of specific substyles - for anything - is rich and flexible. This is what we did in the first iteration of our system. However, it comes with costs and so we kind of moved away from it for the time being.

The biggest cost is this: when you just want to add a simple effect, like shadow, if this is done via adding a new specific substyle, you spend most of your time creating a new substyle and managing it (setting its position in Z order, etc) rather than specifying parameters for the actual effect you want. The UI also spends a lot of controls on managing substyles rather than on actual effects. In the dialog on your screen, for example, you cannot see parameters for all substyles simultaneously. If you want to change parameters for multiple substyles that are somewhat related to each other (say, increase the width of the black line, then increase the width of the red line to keep the black border the same width as before, then increase the width of the bluish padding to make sure it is not too small), you have to be switching between the substyles. Creating a new custom style becomes relatively more difficult, and in the end this means that people just do this less often.

So, what we try to do instead is capture what people generally do with styles (80-90% of scenarios) within a single style with all settings on a single screen.

If we miss something that people use regularly, we can build that into the system as one more set of settings for a single rich style. We have multiple such things already on the way, the current dialogs do not show everything we planned to have. Still, sometimes, even with all extensions, it's still not going to be enough and you will want to have multiple styles. For that, we already allow having multiple drawings on the same data, which other systems do not allow - so if someone wants to combine multiple styles together, they can already do so. If there are pain points there, we can perhaps do something to alleviate them. Finally, if we see people doing multiple drawings (or wanting to do multiple drawings but not bothering because it is still too cumbersome and nothing can help), we can always add an option to combine multiple rich styles together. We aren't against combining multiple substyles within a style - as I said, that was our first iteration, because it is a rather obvious way to do rich styles - we just think we can do better and save clicks / have a better user experience in the majority of cases. If we are wrong about that, we will add substyles. (And if we are right about that, we might add substyles as well, just later.)

Dimitri

5,045 post(s)
#24-Sep-18 10:14

Some brief comments to add to what adamw wrote: it's all very modular inside. The only question is how to expose that modularity to the user in a convenient user interface.

I think there's a lot that can be learned from the way other systems allow creation of complex styles. There is no hesitation whatsoever about swiping good ideas from anywhere. :-) The idea of modularity is certainly a part of that. The question is how you give users access to that modularity.

The Q system is, in some ways, simply a different way of packaging the use of multiple layers to stack symbology so the combined effect is a new symbol. Consider the illustration below:

That's just five line styles stacked one above the other. Add the ability to repeat symbols and offset to one side or the other and it's similar to what the Q symbol hierarchy does. I'm not suggesting the layer structure is the same, I'm just pointing out the modularity is there, with just the question of how you present it within a user interface.

I think the big challenge (as I wrote before) is not providing total flexibility. That's the easy part. The big challenge is organizing the use of that total flexibility into subsets of things that are most used and most desired for quick and easy access. In a perfect world that easy access would require just one click. That's difficult.

I'd be curious to hear what people do all of the time, over and over, that they want at hand with a single click.

Attachments:
stacked_lines.png

Mike Pelletier


1,518 post(s)
#26-Sep-18 19:33

Thanks for asking Dimitri. The current style pane is okay for simple stuff but I think it fails badly for more complicated theming because of it lacks a full preview. Please reconsider the idea that simple formatting should rule the design.

In Mfd 8 I often create a copy of areas such as wilderness areas and then do an inner buffer in order to create an offset line that helps show which side of the boundary is wilderness. This ability is really important in cartography but a huge hassle to perform because the appropriate buffer size depends on the scale your printing. As the project evolves, I often have to redo this a few times and of course it doesn't work well for web maps. This cartographic technique really should be possible in the style pane and it should of course work on lines too.

Forest
578 post(s)
#27-Sep-18 05:47

I actually do the same things and need the same tools.

geozap89 post(s)
#27-Sep-18 08:04

A very common procedure is import a vector drawing (or create it from some data) and then firstly applying a simple style to distinguish it visually in a Map from other Drawings. If there are no other Drawings in the project I might leave it with the default formatting. After that I might not change again its visual style. If the project is "gis/database stuff", usually that's the case. If I have to present to someone the results ("cartography stuff"), then I usually test several styles, especially when several drawings are combined in the final Map/Layout.

For me having the option to change with 2 clicks the style of a drawing is nice, although I usually do that once or two times in every project. So, styling drawings consumes a very little percentage of the time I spent in every project.

I think, instead of having 4 or 5 buttons in the Style Pane to control the various aspects of a style (border, width etc) I would prefer 2 buttons. One that opens an "all-in-one style manager window" and another that opens a drop down list with the already defined styles to chose from. Once you have your library, that's faster that the current way of choosing separately for each parameter.

geozap89 post(s)
#27-Sep-18 08:32

...although having filed driven formatting so simply changeable in the current style pane is nice. I am not sure my ideas about an "all in one" style manager will work so nicely in that case.

Mike Pelletier


1,518 post(s)
#27-Sep-18 17:13

Having preset formats for common things like roads, lakes, streams, parcels, etc would be very helpful and definitely fit into the category of often used formatting. It's also nice to have a handy set of colors that actually match between computer screen and printer to choose from.

Dimitri

5,045 post(s)
#23-Sep-18 08:32

What is the design intention here? Duplicating controls like this is (especially where one set has no effect) looks like a recipe for confusion.

The primary intention is to provide a framework for trying out the new internal capabilities that have been wired up, before committing to any one way of doing it in a published build. There is so much to it that it has to be taken in steps. Part of that is also indicating the need for adjustments in terminology.

The two sets of controls (one in the Style panel of the Contents pane and the other in the Style dialog that is launched by the Style button do have effect: they each have an effect in the context where they work, but that effect does not carry over into the other context.

There's an example of an adjustment in terminology that the new capabilities suggest: consider the current names for the style parameter wells for, say, areas. They are now called "color" (often referred to as foreground color), "back color" (often referred to as background color), "style", "size" and "rotation." Calling that third button "style" and calling what it launches the "style" dialog is no longer right. I think we should change the nomenclature on those properties so that the buttons, in order, are called "Stroke Color", "Fill Color", "Symbol", "Size", and "Rotation."

The "Symbol" button can launch a "Symbol" dialog. That's what ESRI calls it, "symbology," which is a good word in this context. Calling it a "style" dialog is wrong, since we want to use the word "Style" to mean a collection of parameters for areas, lines and points that all together represent a particular look, the way ESRI captures in their .style or .stylx files for a project, or the way web people use the word "style" in settings such as style sheets. But, for now let's refer to the Style dialog using its current name...

Onward:

The preview pane in the Style dialog has its own controls so the preview can be manipulated without regard to what is specified in the Style panel. It provides a way of getting a preview without committing to that preview, similar to how the Transform and Select panels provide a preview of what a template does without committing to that.

The buttons in the Style panel are "instant effect" buttons. Click the stroke color from a default black to red, or the fill color from gray to white and it changes instantly in the map. No preview. On the one hand that's convenient but on the other hand there are obviously ways in which one wants that to be evolved. For example, I'd like a "back" capability for those times when I click the wrong color. [there will be a style history that allows such things conveniently].

Right now, the preview pane in the Style dialog has its own controls that are not driven from, and which do not drive, the controls in the Style panel in the Contents pane. That allows a completely free-form tinkering with the preview. It's a matter of taste whether you like that or not. I've been working with it for over a week and I don't particularly like that. Other people like it a lot and they prefer the preview should start from defaults.

They point out that starting with defaults in the preview pane is a known starting point in all cases: it makes it possible to show long lists of different styles and halos and font symbols and such in totally default style where they always look the same all the time, and then in the preview different combinations can be tried out.

There is the argument that if you launch the preview pane within the Style dialog by inheriting current settings from the Style pane, what you get in the preview can be radically, visually different, and confusingly so, from the default rendering for the base symbol and halo, not to mention complexities when even more variables are available. That can be extremely confusing. What to do? Render a possible symbol font using the current settings from the Style panel? If it happens to use transparent fill color, would that not make a radical difference in the way those lists of symbols appear, seemingly different from what they are in other cases?

Remember, you have to keep in mind what it will look like when there are many more options. Even just now, consider a case of points where the fill color can be transparent or where previously the stroke color or fill color for a halo in use across an entire layer (that is, not defined via override for just one point) can radically change how the preview starts, if it inherits all prior settings.

The contrary argument is that such confusion is easily resolved by inspection, by seeing the settings the dialog displays. Then the counter-counter argument is OK, why not then fatten the dialog with all sorts of controls that affect the visualization - all of them - in which case you break down the categorization of controls that helps keep very many complex possibilities organized.

I'm just saying it is a legitimate discussion to have where people of good taste and experience can have different opinions. I would prefer more linkage where the preview launches with existing settings, and then as you change them would give the option of pushing them out to the main panel. Other people disagree and I can understand and respect their reasons.

Doing it the way it is allows people to sample this way of doing it and to provide feedback, since what is important is what the community prefers overall. Feedback is key. I just ask that people keep in mind that instead of just two or three sectors of options there could be more. Ideally, it would be nice to do that without having to launch many levels of dialogs within option dialogs, but also without too much clutter at the same level.

I don't think, by the way, that the best approach is to replace the Style panel with an all-in-one super dialog. There should be at least one level of "super simple" that is very quick and easy to use, with a hierarchy of greater complexity and total flexibility tucked away where it won't get in the way of quick and easy, simple work. You have to have some compartmentalization of all that flexibility. My own view is that the best approach is simpler panes at the top level for the way most people work, with easy ability to call pre-defined styles in a point-and-click way that experts have crafted from a deeper level of user interface that allows creation of arbitrarily complex styles.

KlausDE

6,229 post(s)
#23-Sep-18 15:31

Here is the german ui file for Mfd 9.0.168.2. You will not notice many effects.

The primary intention is to provide a framework for trying out the new internal capabilities that have been wired up, before committing to any one way of doing it in a published build. There is so much to it that it has to be taken in steps. Part of that is also indicating the need for adjustments in terminology.

Probably that's why the newly defined localized strings are not used in the custom ... style dialog.

What makes it hard to test is that the dialog starts with the default settings and not with those used at last.

Even more puzzling is the setting of margins in the 'page setup' dialog, a system dialog that is not filled with default but with permuted values for left, right, upper and lower margins. I guess the implementation is a hack and tech planes to replace the system dialog dialog.

Attachments:
ui.de.txt

Dimitri

5,045 post(s)
#23-Sep-18 15:46

What makes it hard to test is that the dialog starts with the default settings and not with those used at last

? Can you give an example? All of the dialogs I've launched have previously remembered settings, such as the font and symbol used for a point symbol when a font has been selected, stroke width and so on, still there.

Could you mean the preview? If so, see my other essay in this thread on why that is the way it is.

KlausDE

6,229 post(s)
#23-Sep-18 18:53

In case of the style dialog it's the initial default state of preview inset that puzzles me. I can't remember I've come across such a dialog behavior before. I guess I can't rate the handling of the preview before the following observation ist checked:

Playing around with line styles I noticed that without record or field based formating I receive different line styles dash-dash, dash-dot or dash-dot-dot in one drawing and I can't reliably reset them. This line style changes in different segments of the same area border when I just zoom in or out. I guess that was what made me think of a unreliable preview.

In case of the margins in page setting seems to be a bug, too.

Dimitri

5,045 post(s)
#23-Sep-18 19:12

In case of the margins in page setting seems to be a bug, too.

Could you provide a specific example? There is no "page setting" dialog, but there is a File - Page Setup dialog which appears when a Layout window has the focus.

That dialog seems to work fine, the same as it has the last six months or so. It is a standard Windows dialog as seen in many products. Is that the dialog you meant? Does it look different from the illustration in the topic or work differently than it usually does in Windows?

KlausDE

6,229 post(s)
#23-Sep-18 22:48

Attached is a screendump showing a layout on a landscape A4 paper format with the bottom margin set to 10 divering from other margins. When you open the File->page setup dialog again it comes up with a A3 portrait an the top margin preset as 10.

Attachments:
Page setup.jpg

Dimitri

5,045 post(s)
#24-Sep-18 09:28

If I understand correctly what you are saying, you are looking at two different things. In one display you are looking at the position and size of one frame within a layout. You're not getting information on the size of the sheet of paper being used, or on the margins of that piece of paper.

In the other display, you're getting information on the sheet of paper used by the printer and the margins assigned for that sheet of paper.

The background display in your illustration: In the Style panel, a standard Manifold pane, you are getting a report on the position and size of a frame.

Position - The lower left corner of the frame is positioned 10 mm up from the corner of the paper and 25.4 mm to the right of the corner of the paper.

Size - The frame is 184.6 mm high and 271.6 mm wide.

The foreground display in your illustration:In the Page Setup dialog it is showing an A3 sheet of paper with margins set for left / right / top / bottom as indicated. The left and bottom values are the same as the left corner position of the frame that is the subject of the Style display, but that's just a matter of the frame having been snapped to the lower left margins of the page. If you had moved the frame elsewhere the numbers would not have coincided.

adamw


8,139 post(s)
#24-Sep-18 10:29

The numbers in the Page Setup dialog are margins, applied to the entire page.

The numbers in the Style pane are left - right - top - bottom *coordinates* of the specific layout frame. If you let a layout frame fill the whole page sans margins (the area indicated by the thin gray lines), the left and top coordinates of the frame will coincide with the left and top margins, but the right coordinate will equal page width - right margin, and the bottom coordinate will equal page height - bottom margin.

Can we make these things the same? Possibly. Eg, we could provide an option in the Style pane to view right - bottom margins instead of right - bottom coordinates. Or we can change the system Page Setup dialog to our own (we have other reasons to do this as well, it was just not a super-high priority) and let that dialog display coordinates instead of margins. But there is no bug, the numbers in the two places are different because they are different - although related.

KlausDE

6,229 post(s)
#24-Sep-18 11:59

For the purpose of better visibility than only the light grey margins here (a perfect color usually) the map frame fills the complete printable area inside of the margins. I focus on margins only.

As you say the bottom margin is set to 10. However when I open the File->page setup dialog once again it comes up with a top margin of 10 ("top" = "Oben" in my german system) and with wrong orientation and paper size.

So if you just leave the unchanged dialog with OK you get a complete different result.

That can not be expected behavior.

adamw


8,139 post(s)
#24-Sep-18 12:39

I see now (orientation / page size are wrong, so margins apply to different sides - the value of 10 for 'top' is still being applied to 'top', but since orientation was lost, this is a different side).

Yes, this is a bug. We will fix it. Thanks for the report.

Dimitri

5,045 post(s)
#23-Sep-18 19:13

Playing around with line styles I noticed that without record or field based formating I receive different line styles dash-dash, dash-dot or dash-dot-dot in one drawing and I can't reliably reset them. This line style changes in different segments of the same area border when I just zoom in or out.

Are you working with lines or with areas? It sounds like you are working with areas and are changing the border style. Is that it?

Create a new, blank drawing and enter some lines. Can you set the style for those lines OK?

Ah... one last thing: in Tools - Options, is the Graphics engine set to Normal?

KlausDE

6,229 post(s)
#23-Sep-18 23:12

I guess I found the special condition that produces changing area borders and though surprising ist probably not a bug.

The attached file contains a drawing of versioned area. Area that have not been changed overlap exactly. And so do the area fill patterns.

But not the border lines. They seem to start with the pattern at some unpredicted location and are displayed as combined line type. At least I guess that is what I see and what changes redrawn with a separat scale.

Graphics engine ist set to Normal in Options.

(BTW the file contains the layout producing the puzzled File->page setup dialog.)

Attachments:
Dash_AreaBorders.mxb

Dimitri

5,045 post(s)
#24-Sep-18 09:40

When the effect for an area border is a dashed line that has intervals of transparency, you can get effects like that when area borders of two different areas are exactly coincidental. It's like a moire pattern because the starting position of the dashes is not guaranteed to be the same.

Consider the display above: the mixed pattern appears where area borders coincide.

Move the areas apart and you see the pattern and how the dashes are not all in the same places.

To avoid the effect, either a) use a solid line style for area borders or b) wait for an improvement that fixes this :-)

Attachments:
area_borders01.png
area_borders02.png

KlausDE

6,229 post(s)
#24-Sep-18 12:09

I would expect borders of adjacent area to show mixed patterns, even if the are displayed with the same formating parameters.

What puzzled me is that the overlay of identical area geoms produces an overlay of not identical border line patterns in different segments of the two boundaries- if that really is what I see.

Dimitri

5,045 post(s)
#24-Sep-18 13:11

What puzzled me is that the overlay of identical area geoms produces an overlay of not identicalborder line patterns in different segments of the two boundaries- if that really is what I see.

A fatter border is rendered on the centerline of the area's actual border. Suppose it is a dashed border with a stroke thickness of 10 points. 5 points of the thickness of each dash will be inside the area and 5 points of thickness of each dash will be outside the area. An adjacent area which is drawn above that area will overlap, that is, cover, those five points of the dash which fall underneath the overlapping area.

Consider the above two illustrations. The illustrations show areas that have borders drawn with fat dashed lines. The green area uses a blue dashed border, and the beige area uses a black dashed border.

Above are the areas drawn together, with the green area rendered above the beige area. The illustration at left has no transparency for the green area, so where the green area covers parts of the black dashes they seem thinner. The illustration at right, with 50% opacity for the green area, shows how it partially covers some of the width of the dashes used for the border of the adjacent area.

Changing the color of the dashed border for the green area from blue to black shows the "uneven" dashed figures seen in the illustrations I posted earlier.

By the way, the above effects are fairly common in any GIS that provides an option of rendering area borders with dashed lines that include transparency between the dashes.

Attachments:
overlaps01.png
overlaps02.png
overlaps03.png
overlaps04.png
overlaps05.png

KlausDE

6,229 post(s)
#24-Sep-18 17:02

Well, my area have no neighbor but sit one on top of the other.

And I can't help, it's not looking like the overlay of shifted patterns of the one and only border style used with this one drawing.

Aktually it's looking like different border styles applied to different 'arcs'.

Attachments:
AreaBorderStyle.jpg

adamw


8,139 post(s)
#24-Sep-18 17:10

Can you post the drawing with the objects?

KlausDE

6,229 post(s)
#24-Sep-18 17:12

It's in the map file attached here.

adamw


8,139 post(s)
#24-Sep-18 17:28

Thanks.

As you said, your areas sit on top of each other. I Ctrl-clicked into the left area (the one with the border that looks like dash-dot on the top and dash on the bottom) and there are two areas there: MFD_ID=5 and MFD_ID=10. The first area has 192 coordinates and the second 190, so perhaps the coordinates mostly coincide, but I guess the two extra coordinates create a skew and so dashes for the first area either start with an offset compared to the second or get that offset some time into the shape. This is actually further exacerbated by the fact that the window does not render an entire border (we don't render what's not on the screen), but in general, if the desire is to have the dashes of *two areas* match and produce some known shape, then that's a bit of a challenge in any system that performs any kind of optimization during rendering, not just in 9. Now, we do have a solution in mind which requires post-processing, but in general, matching borders of areas simply because they happen to go on top of each other - whether with areas that are contained in each other or adjacent to each other - is not something one can just expect to happen automatically, it can only happen if the system takes specific measures for it to happen (what we are planning to do) or by luck.

Same for lines that end up being following each other for some time - unless the system specifically tries to sync rendering for the overlapping parts, the results are just going to be unpredictable. If you want the results to be predictable in any system, you have to normalize topology and get rid of the overlaps.

KlausDE

6,229 post(s)
#24-Sep-18 17:31

Well, my solution will be to delete the (nearly) duplicate objects ;-)

And perhaps invent a better way of versioning without duplicates at all. But that's another question.

adamw


8,139 post(s)
#24-Sep-18 17:32

...or make borders for non-latest versions of the objects invisible.

adamw


8,139 post(s)
#24-Sep-18 10:12

Now in the bottom panel of the same Custom control, beside the preview, I choose foreground and background colours, a scaling size of 15pt, and a rotation of 45°. Again, I can see the effect of these settings in the preview. I OK out of the dialog.

But those last four settings--foreground and background colour, scaling size, and rotation--seem to have no effect. The effective settings are instead governed by (duplicate?) controls in Contents > Style itself (the first, second, fourth and fifth controls).

If I now open the Custom... dialog a second time, the settings I made before in the bottom panel (foreground and background colour, scaling size, and rotation) are reset to their defaults.

What is the design intention here? Duplicating controls like this is (especially where one set has no effect) looks like a recipe for confusion.

This echoes in several other posts, answering it all here.

The design intent is this (sorry for not communicating it clearer):

The Style pane has buttons for individual parameters: color / fill color / style (we will likely use another name here, with 'style' meaning a combination of all parameters) / size / rotation. When you click a specific button, you change the corresponding parameter and nothing else. Eg, when you change the size, colors do not change.

When you click a specific button, sometimes the dropdown menu has a 'Custom...' choice. This choice is there because the dropdown menu cannot fit all available choices. When you select 'Custom...', you get a dialog which shows all available choices for the parameter you clicked and allows selecting the choice you want. So, when you click 'Custom...' for a color, you end up selecting a specific color. And when you click 'Custom...' for a style (again, we will likely use another name here), you end up selecting a specific style. Same as when you specify a custom color, all other parameters (the other color, size, style, rotation) stay the same, when you specify a custom style, all other parameters (colors, size, rotation) stay the same. The controls for colors, etc, in the right-bottom of the style dialog are just for the preview. They are there to let you see how the style is going to look with whatever colors, sizes, etc, you are planning to use it with. Note that size, for example, starts at what typically is a much higher value than the one used in the map - 24 pt for points, etc - this is to make the preview larger so that one can see the details of the choice more clearly. We did not intend the preview controls to act as means to select the actual colors, etc, for use in a component - for one thing, it would be hard to specify thematic formatting then, there's just no room for those controls in the dialog nor we think they belong there. The preview controls are just there for the preview.

That said, we see that the dialog does not do a good job at communicating which controls are persistent and which are temporary. This should be sorted out. Further, after seeing feedback in this thread and elsewhere, we think it might be useful to have means to actually let the dialog control all settings and edit all style parameters together - as an option (we are absolutely not going to lose the way to let different fields control different parameters, not trading off any flexibility). We might have an idea here, which we will try to present in the next build.

Mike Pelletier


1,518 post(s)
#25-Sep-18 00:54

I'll echo the sentiments about the custom dialog not controlling the full final look of vectors. That is quite confusing.

Perhaps a part of the solution your cooking is a preview pane also in the main style pane? Seems like there is room and it would be helpful sometimes to see what the controls are set to without having to zoom to the right spot on the map to see them.

I'd really like to see the ability to draw a second and third line (with all the current controls for dashes, etc.) to the left or right of the main line and not just underneath it as it is currently. This is really important for cartography and should also work with area perimeters.

Glad your prioritizing redraw speed, although I'd be willing to lose some for better cartography.

Mike Pelletier


1,518 post(s)
#25-Sep-18 03:45

Why not make the style dialogue work more like a legend for the active layer by showing full preview for points, lines, and areas? If this could be made to work, it would greatly help users see the full effect of all their chosen settings without relying solely on zooming around the map to see how it looks.

Perhaps have the 3 previews side by side across the top of the pane scaled to be readable. Below have all the main parameters: foreground, background, symbol (areas > hatching, lines > extra lines, points > shadow, etc.), stroke, and angle using button a bit smaller than currently used. The user clicks on a preview to set the parameters available for that vector type. Compared to the current method, this takes one extra click to see the settings for a particular vector type but it provides a clearer view of the settings and saves space in the pane by removing repetition.

When a thematic formatting is applied to for example points, the preview changes to label like “Themed Point” and the preview is provided at bottom of the pane with all the applied settings including other parameters using themed formatting. When user selects symbol (I think that is the new term) the additional parameters such as dash width, padding, etc. should appear in the style pane when possible. If a separate custom window needs to open, the preview of the selected changes should appear in the style pane preview instead of a preview in the custom dialogue.

I'm sure there are holes in this but hopefully it spurs some helpful ideas.

tjhb

8,280 post(s)
#25-Sep-18 03:56

Thanks for explaining that so clearly Adam. I understand the intention now.

Since there is more to come in these dialogs, not yet visible in public builds, it's hard to say what will feel intuitive in the end. For now I think that if there will be both (a) persistent controls, and (b) controls that only adjust the preview (seeing the preview as mostly a "sandbox", mainly there for experimenting), then yes it would definitely help for (a) and (b) to be clearly distinct, even to the point of keeping them in separate dialogs. Maybe also for current persistent settings to initialize a new preview; and for there to be means to make all preview settings "stick" (as far as applicable), i.e. override current persistent settings. I doubt these comments will be very useful but there we are.

Dimitri

5,045 post(s)
#23-Sep-18 15:43

What the "width" parameter is for next to standard symbols for points, in the expanded Style dialog:

Pick a point symbol like a square or one of the flags. Change the width to 40% and the symbol gets narrower. 100% is the max, it seems.

StanNWT83 post(s)
#24-Sep-18 17:05

Hi Adam,

I'm wondering if I should be putting in a request for mult-ring buffers and the kinds of options that I'm thinking of for multi-ring buffers in a transform in a new edge build?

You can read through the thread and at the bottom you can read the kinds of uses I put to multi-ring buffers.

adamw


8,139 post(s)
#24-Sep-18 17:13

Yes, sure. Whatever you need, send it in as a suggestion. We do tend to batch up things in a particular area for cutting edge builds, and the focus area for the current series of cutting edge builds is cartography, but (a) we always add things outside of the focus area, and (b) there will always be other series of cutting edge builds. The sooner you send the requests in and the more specifics the requests have, the better we can organize them and the faster they get to be born as features / adjustments or extensions to existing features.

StanNWT83 post(s)
#24-Sep-18 17:48

Hi Adam,

Where do I send in the suggestion?

adamw


8,139 post(s)
#24-Sep-18 17:54

See this: Suggestions.

(Don't be intimidated by tons of details, most are just tips to make sure you spend time on what's important vs what isn't.)

dchall8
501 post(s)
#24-Sep-18 18:24

PDF Printing Feedback

PDF printing is quick and extremely quick compared to M8. There are three issues I've found with the output.

1. is illustrated in the first attachment (PDF Print from 45x24 Layout Compared.jpg). The Layout Page Setup is set to 45x24 (width by height) in the Portrait mode. When I print to the Adobe printer, the results are as shown. The print is cut off at about 28 inches wide. It appears like the file was printed properly to that point, and the rest of the file are compressed into a sliver of pixels.

2. The line width is different in 168.2 (illustrated in second image, PDF Print from 168.1 and 168.2 Layout Compared.jpg). Line weight in 168.2 is too coarse. Settings in Style make no difference to the print. On the plus side, the coarse line weight hides errors in vertex snapping.

3. When I set the Page Setup to print 90 inches wide by 72 inches high, I get an error immediately when printing to Adobe. The error says, "Cannot complete pring (sic) job."

Attachments:
PDF Print from 168.1 and 168.2 Layout Compared.jpg
PDF Print from 45x24 Layout Compared.jpg

danb


1,656 post(s)
#24-Sep-18 22:53

While we are talking about styles and rendering, is it worth mentioning mini charts and their like? I frequently found these very useful in M8, though my principal difficulties with them were including the chart in the legend and sensible placement of the chart on the map. I am unsure of the demand for such a feature in 9 so this might be better sent as a suggestion.


Landsystems Ltd ... Know your land | www.landsystems.co.nz

adamw


8,139 post(s)
#25-Sep-18 07:45

Yes, send that in as a suggestion. We did talk about minicharts and we do want to bring them in (and improve / extend, we love such things and have lots of ideas as usual), but this does have to compete with other things. Even if we don't do full minicharts right away, we will likely have an intermediate solution where you would be able to build minicharts for a couple of parameters using one or more drawings with matched point styles.

adamw


8,139 post(s)
#25-Sep-18 07:49

Thanks a lot for the note, we'll look into everything.

With 2, what happens if you print to a different printer driver - eg, to 'Microsoft Print to PDF' or to a physical printer? I also take it that this is Normal graphics, not Reduced graphics (see Tools - Options), correct?

dchall8
501 post(s)
#25-Sep-18 15:59

Normal graphics, yes.

Windows 7 here so I don't have Microsoft Print to PDF. With FreePDF it crashes upon clicking the final Print button. "Cannot complete print page." With CutePDF I get the same result as with Adobe. The thickness of the lines seems to be slightly less, but not like the thin lines from 168.1. It is interesting that the page size is as specified, but the image is not.

When I print directly to our HP Designjet 800PS 42 plotter set to ANSI F size drawing, it gives me the center of the Layout at ANSI F size. Interestingly, the east portion of the center of the drawing extends further east than the PDF print. I fiddled with settings and printed again trying to shrink the output to full size, but it printed the same center of the Layout on the F size paper.

When I print to a Canon iR-ADV C3325/3330 printer at letter size, it prints the center of the Layout at letter size. I cannot seem to find a way to reduce the size of the output to fit into the format of the paper I'm using.

With M8 I Exported the Layout to PDF simply because it was much (MUCH) faster than printing oversize to a plotter. With M9 it seems to print to a device about as fast as printing to PDF, but when printing from Adobe I have some control over page scaling.

I printed to PDF at different sizes and what seems to be the limit is 28 inches wide.

Attachments:
ANSI F, D and C Output from M9.jpg

tjhb

8,280 post(s)
#25-Sep-18 16:47

From your previous post:

1. is illustrated in the first attachment (PDF Print from 45x24 Layout Compared.jpg). The Layout Page Setup is set to 45x24 (width by height) in the Portrait mode. When I print to the Adobe printer, the results are as shown.

Don’t those dimensions entail and require landscape mode? Could this explain the lateral truncation?

dchall8
501 post(s)
#25-Sep-18 18:40

I create the custom sizes using Acrobat. When it goes into Acrobat it is in the portrait mode but the dimensions are, say, 90 wide by 75 tall. When you create a print size in Acrobat it seems to assume the portrait mode, because you cannot specify. When you print something to Acrobat you have all those custom option sizes available. In creating the ANSI sizes I could specify wide or tall

If I have the standard ANSI C size it will be 17 wide by 22 tall. In Manifold I would have to use landscape mode for my wide county to fill the page. But if I design the page to be 22 wide and 17 tall, then I can leave it in portrait mode.

tjhb

8,280 post(s)
#25-Sep-18 19:14

That really doesn’t sound right. You can specify portrait or landscape mode in Acrobat, at keast at print time. (I will have to check the options for creating a custom page size.)

What version of Acrobat are you using? I can try to replicate.

dchall8
501 post(s)
#25-Sep-18 19:34

Acrobat 9.0.0 Standard. There seem to be no updates available.

To create a new print size I select Adobe as the printer, go to Preferences, and click Add to the right of the Adobe PDF Page Size.

tjhb

8,280 post(s)
#25-Sep-18 20:23

Thanks, I'll try the same and see what I get. In Acrobat 10.

(We both should have upgraded to version 11 and now 'DC'. But perhaps like me you dislike Adobe's subscription model and the bloat that goes with it.)

dchall8
501 post(s)
#25-Sep-18 21:50

Agreed. I don't remember what version I had on an old computer, but it allowed me to edit layers to turn them off and resave so the default was only one activated layer with the rest hidden. That was 2004 when I first got Manifold. Our client at the time bought me anything I wanted when she saw the maps.

adamw


8,139 post(s)
#02-Oct-18 16:09

Status report: we are planning to publish the next cutting edge build at the end of this week. Lots of fun with styles plus various fixes and improvements in other areas. :-)

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