Symbol Origins

[spatialdude]

Hi

This symbol set is great.

Is it possible to also add to the repo a file with x,y placement origins for each symbol?

This could be as simple as a 0 -> 1 values in each axis from from the top left corner within the icon's bounding box, that way it would work for all sizes of each symbol. e.g. 0.5, 0.5 = center, 0.5,1 = bottom center.

If the file is a simple CSV in the format - <name>,<x-origin>,<y-origin> - then it would be easy to read in code. The name would not include the size. -

esri-pin-one,0.5,1 esri-pin-two,0.5,1 hexagon,0.5,0.5

[sfrizzell]

I wonder if a standard for precise cartographic symbol placement has been established to address this alignment issue. Maybe Craig Williams or Edie Punt would have experiential knowledge of this.

@paulcpederson

[paulcpederson]

I think the icons just need to be centered in their art boards? A majority are both vertically and horizontally centered, but some are pretty egregiously off-centered. I believe if they all were optically centered within the art board, devs could assume center placement (ie. .5,.5).

The artboard sizes are odd-numbered and square, which should make pixel-perfect center a realistic goal for this set.

[spatialdude]

@paulcpederson Assuming 0.5,0.5 for most makes sense if their centring is cleaned up. What would then be the programmatic method to identify the 0.5,1 placement which is appears to be the only other case that is needed for the pin style symbols?. I think would be ok if the placements reference file only contains the exceptions and assume if the symbol is not in the list then it is 0.5,0.5.

[SkyeSeitz]

@paulcpederson taking a look at what you pointed out and noticing that the icons that appear super off-center is because they are 17px symbols being aligned to the top left corner of a 21px space. They are centered in their files. Can we look at centering them in the cards? Would a tab or toggle for sizes be helpful as well?

[paulcpederson]

@KatelynSeitz ok, that makes way more sense. I seem to remember many sizes are missing right now. So those are probably rendering that way because their larger glyph just isn't there and I wrote it to fall back to smaller sizes if available. I think as glphs get added to the set, those should be fine. The plan is to eventually have consistent sizes across the set, yeah?

@spatialdude OK, I understand better what you're getting at. It seems like it's really just a list of bottom docked vs center docked. We could maintain a json file or something with a list of bottom docked icons (I think horizontally all icons seem to be based around the artboard center?)

[SkyeSeitz]

@paulcpederson Yes, I think consistent sizes across the set would be great. However, I am not sure if there is a timeline set to that just yet.

[spatialdude]

@KatelynSeitz Yes JSON file is also good. A couple of suggested JSON structures might be -

Array style

 [
    {
        "name": "esri-pin-one",
        "x": 0.5,
        "y": 1
     },
    {
        "name": "esri-pin-two",
        "x": 0.5,
        "y": 1
     }
]

Named objects style

{
    "esri-pin-one": {
        "x": 0.5,
        "y": 1
     },
    "esri-pin-two": {
        "x": 0.5,
        "y": 1
     }
}

• If a name is not present x,y are assumed to be 0.5,0.5
• If an axis is missing in the object it is assumed to be have the value of 0.5. This then lets you keep the file even smaller and only specify the axis that does not have a 0.5 value

Even though there only appears to be two cases at the moment, you never know what exciting symbol you come up with with a different origin. e.g. I can imagine a callout type with the origin in a corner... e.g.

[sfrizzell]

There is not a plan at the moment to fill in the additional sizes for symbols that were only built for a 21px art board (those that were not also built within 13px and 17px art boards). This has been a point of discussion. How we present/account for the mix of available scales needs to be resolved. @nicklu10 @julio8a

[spatialdude]

Hi Below is what I've come up with for Survey123 and our other apps.

Any symbol not listed is assumed to have the origin 0.5, 0.5.

There were not many exceptions so it was pretty easy to come up with the list.

I've set it up so all the symbols get converted to fonts via scripts. The whole process is very simple now to maintain when any calcite icons or symbols are added or updated.

The screen shot shows a simple symbol chooser, with an option to see the placement origin for testing purposes.

{
    "box-pin": {
        "xorigin": 0.5,
        "yorigin": 0.85
    },
    "flag": {
        "xorigin": 0.35,
        "yorigin": 0.85
    },
    "esri-pin-one": {
        "xorigin": 0.5,
        "yorigin": 0.85
    },
    "esri-pin-two": {
        "xorigin": 0.5,
        "yorigin": 0.85
    },
    "pushpin-one": {
        "xorigin": 0.5,
        "yorigin": 0.85
    },
    "pushpin-two": {
        "xorigin": 0.5,
        "yorigin": 0.85
    },
    "tear-pin-one": {
        "xorigin": 0.5,
        "yorigin": 0.85
    },
    "tear-pin-two": {
        "xorigin": 0.5,
        "yorigin": 0.85
    }
}

[spatialdude]

FYI

• We've moved to using only the 21px symbol set for Survey123
• Additional symbol origins have been added