mapper
mapper copied to clipboard
Secondary point symbol
Steps to reproduce
- Export from Ocad MTBO symbol set - symbol Forbidden route
- Import into OOM
- Skipped secondary point
Actual behaviour
Secondary point missing. See zipped att.
Expected behaviour
Correct import
Configuration
Mapper Version: 0.9.5 Operating System: Win
Confirmed. Mapper issues a warning on import ("In line symbol 711.0 'Forbidden route (automatically)': Skipped secondary point symbol.") but I don't see why the import routine skips the secondary symbol.
Minimal reproducer created with OCAD 8. There should be dots and squares alternating on the line. ocad8-minimal-reproducer.zip
Output with OCAD 12
Making progress....
The else if (attributes.secondary_data_size > 0) part has a number of issues (of which the first one is the 'else' of course).
Removing the line_symbol->mid_symbol = new OcdImportedPointSymbol(); and replacing the 'elements' parameter in the line below by reinterpret_cast<const Ocd::PointSymbolElementV8*>(coords) leads to something like this:
I manually modified the symbol in Mapper (see attachment). However, adding the 'falling' rows with an offset leads to adding an offset to the end symbol and thus will lead to a line getting longer as configured. I don't see an easy way to import these kind of OCAD symbols as OCAD treats the secondary point symbol in combination with the main one, whereas Mapper processes all line parts forming an element (e.g., the mid element) independently. BTW: you will experience a weird behaviour if you keep the checkmark at 'Secondary symbol B' while setting the number of Main symbol A to 0 in OCAD.
Thanks @ollesmaps for reporting. "Secondary symbols" do not have a natural counterpart in Mapper, and until now they didn't seem to be necessary. So adding them is not "low-hanging fruit".
As done with some OCD symbol configurations, this particular use case could be mapped to a combined symbol. This won't be fully accurate, but it might be good enough. The more difficult part is the export to OCD, with rule-based mapping from the combined symbol back to a line symbol.
In any case, the symbol has some quirks depending on the actual line object., in particular for short lines and for curves. Is this expected or acceptable?
Stretching, shrinking or bending the object length will in most cases lead to gaps or overlaps, which would be ok for me,
This is how it looks in OCAD:
This is how it looks in OCAD
Is this the line symbol from the OCD file for the original post, i.e. without conversion to and from Mapper?
Yes, it is the original symbol and it was done in the original OCAD file (migrated from ocd10 to ocd12 when opening), I added the brown curve to show the underlying bend (just as you did).
Reassigning to Kai who has a working fix. All my example symbols render correctly with the changes from PR #1958.
@lpechacek : can you test the fix with the attached ocd files? Both are somehow 'invalid' as I set the number of Main symbol A to 0, so they will only contain the secondary symbol. fobidde-route_ZeroMainA.zip
This is the outcome of the zero number of main symbols (fobidde-route_ZeroMainA.zip):
The previous test motivated me to try multiple main symbols on the line. I never experimented with this setting. At the top, it's OCAD rendering. At the bottom is the Mapper variant. The main symbol is a perpendicular dash, repeated four times. The squares are the secondary symbol.
As seen in the picture, OCAD does not bother squeezing the main symbol into the line footprint. It would be understandable if the interpretation is that the main symbol is centered on the line ends, but the rendering differs at the start and end of line. I'm not sure if we should poke more into this bug nest.
I don't want to deal to much with the undefined behaviours ("somehow 'invalid' ... set the number of Main symbol A to 0") while still dreaming of LineSymbol 2.0 in Mapper. (Well, I somewhat use CombinedSymbol in that way :smile:) However, I would appreciate some robustness around the use cases we want to support, such as that MTBO symbol. In particular, I did not yet tests with any dash style options.