Using SVG for VASL Discussion

BigAl737 commented 4 years ago

I'm opening this topic to record a history of discussion concerning SVG file format implementation into VASL. An older closed thread (#218) provides a little more history.

So what do we gain by using SVG?

To answer this I ran a test, the results of which are in the screen shot below (double click the image to get full clarity).

The top row is normal VASL using a png image for the basic piece and VASSAL handles the rotations.

The middle row uses an SVG image for the basic piece and VASSAL handles the rotations.

The bottom is an SVG image for each rotation orientation using an added Layer trait. VASSAL is NOT handling the rotations. However, all the rotated images in this third example that you see are generated with the removal of the ruCTtur prototype. This is important to point out because with the inclusion of the ruCTtur prototype, VASSAL would handle the rotations. It's interesting to note that the SVG image for each orientation maintains better clarity than the above examples. If VASSAL handled the rotations (i.e. with the inclusion of the ruCTtur prototype), the results were almost identical to the middle row.

As expected, clarity is maintained with SVG images, even when zooming in. What I didn't expect is the improved clarity attained even when rotated through the use of a Layer trait.

A side benefit with SVG images is the improved clarity for backside information (smoke availability, CS, etc). Here's a screen zoomed in at 150%. I can make the superscripts more legible. Same order of formats as above.

The Has Info window amplifies this information as well but simply zooming in on a SVG wreck depiction allows easy reading of the notes information. With this being the case, I don't see the need to use the Replace With Other trait for Wreck depiction. I can generate a Wreck prototype that offers the same menu selection options as the current wreck counters. These menu options could be hidden from view until the Wreck layer is active. The only thing we lose is the ability for different information in the Has Info window. Typically the only thing in that window for a Wreck counter is the CS # and MG armament. Using SVG, the CS# is easily visible now and if you do need to check the MG armament, just momentarily flip the counter over to it's non-wrecked side.

Finally, SVG offers more benefits if the Mouse Over Stack trait is changed to show units in an unrotated state. Here's a screen showing what that would look like zoomed in at 150%. Easy for my aging eyes to read for sure.

For comparison, the top most screen shot shows these same images at 100%.

What are the SVG drawbacks?

You need to start with an SVG image to gain the benefits. Vectorizing a raster image isn't gonna gain you anything. Hence, the vast majority of current VASL images will probably never be vectorized.

An SVG image is larger than a png or gif image. A 60x60 SVG image is about 65kb vs about 6kb for a png image. Eventually the addition of SVG images will increase the size of a module. And remember that to achieve the clarity in example 3 above, each SVG counter contains 6 SVG images.

I do see benefits for SVG though. Markers can be more readily vectorized to achieve better readability. New additions to VASL (like BFPs OtO2) can be vectorized from the get go. VASL can process both gif, png, and SVG in a manner transparent to the player.

I've opened this issue for education and discussion. Please consider what I've posted here and chime in with your thoughts.

Allan

derimmer commented 4 years ago

I know so little about graphic images that I can't really comment. But I will say that the VASL module is currently about 18 MB in size. 16 MB of that is the Images directory.

zgrose commented 4 years ago

I think my response is summarized in these three lines in the OP:

...So what do we gain by using SVG? ...the vast majority of current VASL images will probably never be vectorized. ...VASL can process both gif, png, and SVG in a manner transparent to the player.

I'm not seeing why we should care if you start putting out SVG counters. Only a few counters are affected and VASSAL will handle it all for us anyway. Size is N/A, my GMT modules are clocking it at 60MB+ and doesn't bother me one bit. That appears (to me), zero drawbacks left.

jrvjrv commented 4 years ago

There are a lot, a lot of advantages of a vector image over a raster image, especially for maps. With vector images items are typically a "text description" in xml of what is to be drawn. For instance one way to draw a line is a pair of endpoint coordinates with a description of its features. This is the "text description" for a dashed line with a 4mm width: <path style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:4;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:8,16;stroke-dashoffset:0" d="M 21.922619,40.732143 36.285715,128.42262" id="path83606" inkscape:connector-curvature="0" >

The "d=" part are the start and end points. The "style=" part has the "strokewidth" of 4. I assume there is a place elsewhere that says the defaults units are mm. The "stroke-dasharray:8" indicates how much is blank and how much is color in the dashes. There are many other patterns. There are many more complicated shapes and things that can be drawn. I won't go over the other bits because, frankly, I don't know what many of them do, and when you use a vector drawing program like inkscape you "draw" rather than manipulate the text description. To draw the line above I selected the "draw straight lines" tool, clicked a start point, an end point and hit the return key to terminate the shape. I then changed the style of the line to a dashed line and its thickness to 4. I could have made a complicated shape instead of just one line segment by clicking more points before I terminated the path, and I could have closed (connected the beginning to the end) the path too. I didn't, just to have a simple example to talk about.

The really nice thing about svg images in the context of maps is that they can be changed by programs. If you notice there is an 'id="path83606"' attribute. That means I can programmatically change this line's dash pattern, its color, or even whether it is shown or hidden. You can add custom attributes that you can use to manipulate the xml by groups. For instance if you had a bunch of (closed) paths that had attribute "asl:terrain-type=grain" you could have grain be out of season by turning those paths off rather than using overlays or bit-painting. You could change them to plowed fields by changing the fill. Similarly an "overlay" is just inserting some more svg xml code into the image.

There are three downsides that come to mind. First it's different to make things look good in svg. For example with a raster (jpg or gif) image I can "smudge" a border to make it look natural and less sharp-edged. There are features in svg that do similar things, but they are different, and I think most of the map talents that are currently working are exceptionally skilled with raster programs (gimp, adobe illustrator, etc) but not as familiar with svg programs. I have made very primitive svg maps (basically color-filled outlines) for playtest of KGS but I have no idea what it would take to make them "production ready." I can say for the primitive map of KGS it took almost no time to generate one. I started with a .jpg of a pencil drawing and "traced" the shapes over it. I worked over several days but the map was/is big, not because the process was difficult.

The second downside is that it would probably take a good deal of work to allow a programming interface into the .svg. Perhaps a first step would be to allow .svg images for maps without any new capability to access them programmatically.

The third downside is that going back and retroactively changing existing maps would be painful and might even be beyond the realm of the possible.

For me the maps are the big win with svg. You don't often change counters other than rotating them, although things like wrecks might be implemented differently using svg. One could imagine a "vanity" feature to allow users to select a camouflage patterns on vehicles rather than a straight color, but it wouldn't be an essential feature. Perhaps a feature that might be useful for both maps and counters would be to allow changing of font size for players who find their eyes strained and counter and map color for color blind players. I don't know if there is a need for either of these, but with a programmatic interface into svg they would both be possible. The interesting thing here is that the changes could be made so that one player sees them but the other player does not.

BigAl737 commented 4 years ago

After reading the responses so far, I think I have a plan for the OtO2 addition to the BFP extension. I"ll use option 2 in the OP. OP 3 doesn't gain much but greatly ramps up module size and introduces some other problems that would need to be fixed with the addition of new prototypes.

JR, I agree on the SVG benefits for maps and appreciated your comment. I recall having tried SVG maps in VASSAL and though I think they are supposed to work, they didn't work or they were so fiddly I just gave up trying to make them work. Most likely operator error on my part. Further, VASL requires maps to be in gif format...at least I think so. I just tried doing the OtO2 map in png format and VASL couldn't read it. That's probably operator error too.

Back to the benefits for SVG counters...I think a huge benefit is realized when the Mouse Over Stack Viewer show images in an unrotated state. It's a little off topic but are there any objections to changing this in VASL for the upcoming release?

derimmer commented 4 years ago

VASL6.5 will fix the limit on .gif maps only. So long as the board is not a "legacy board", VASL will impose no suffix test. it will grab the mapboard name from the BoardMetadata.xml file. So long as it is a valid graphics file it should work. You will be able to try it when I release the beta this week (there was a bug that I just fixed today so don't try it on the pre-release modules I had shared earlier).

jrvjrv commented 4 years ago

One nice possibility if you change from raster images to vector graphics is that you can get rid of the requirement to use particular colors for the LOS engine. I believe right now the LOS engine looks at pixel color to determine the terrain, and a different color—even slightly different—may confuse it. With a vector image you can use intersection calculations rather than looking at the pixels. To be clear, this may be a non-trivial programming exercise. But it would allow for different artistic schemes.

BigAl737 commented 4 years ago

That would be way cool! Doug can have it programmed in a matter of minutes I'd bet.

derimmer commented 4 years ago

I can't program my coffee maker in minutes, let alone VASL! LOL.

Sounds interesting as the way the los engine works now can cause issues. I am not clear on what "intersection calculations" are or how they might be helpful?

jrvjrv commented 4 years ago

I am not clear on what "intersection calculations" are or how they might be helpful?

Windowing systems (such as x-windows or microsoft windows) worry a lot about drawing multiple windows on screen and how those windows interact or overlay. If, for instance, one window completely covers another, when that covered window "changes", there's no point in repainting it because it's under another window and the change won't be seen. If you move the top window so that the bottom window is partially visible, ideally you'd like to spend as little effort as possible drawing the bottom window. For that sort of work you need to be able to calculate whether two windows overlap and where and how much. There are various algorithms that will calculate whether window rectangles overlap, and I am fairly sure there are similar algorithms that will calculate whether a lines cross rectangles. If you get a "yes", you can use that in a LOS engine to say the LOS is blocked (for rectangular regions). I don't know but I would guess there are similar algorithms to calculate whether a line crosses a bézier curve (I expect in a vector graphics map that features would be constructed of paths of bézier curves). There are similar problems in game physics (does this "moving object" hit that "stationary object", and if so when and where?), so I think the math is all worked out somewhere.

BTW in vector graphics "Bézier curves" are one of the principle drawing elements. They actually show up in raster (pixel) drawing programs such as gimp as "paths" I don't know Illustrator, but I assume they are in there somewhere too. If you have used them (even without knowing it), they are very simple to use. If you have not used them (or don't realize you have) they sound intimidating but are truly not.

derimmer commented 4 years ago

Understood (well, uh, sort of . . .I think).

Not immediately clear to me how we would use this to alter how the los engine works. Would you switch from testing the color of the next pixel along the line to testing whether that next pixel is within a rectangle or area former by those darn Bezier curves? If so, that probably doesn't change the los code that much but nor does it make it better.

Would such areas be created as part of the board making process or would it require additional work at the graphic stage? And would the "different artistic schemes" you wrote of produce better maps? If so, then it may be worth doing even if it doesn't change the los scheme that much.

I ask from a position of great ignorance about vector graphics and not from any reluctance to embrace them if the return is worth the investment. I simply don't know a damn thing. And better graphic boards may very well be worth rejigging the los engine for.

jrvjrv commented 4 years ago

Not immediately clear to me how we would use this to alter how the los engine works. Would you switch from testing the color of the next pixel along the line to testing whether that next pixel is within a rectangle or area former by those darn Bezier curves? If so, that probably doesn't change the los code that much but nor does it make it better.

Vector graphics differ from raster (pixel) graphics in that you have a mathematical description of the entities to draw rather than dots on a grid. An example line might be defined as from point (3,6) to point (27,192) with width 3 (in some units, perhaps inches or mm). There's no mention of the intermediate points, just the end points. For that reason the image is infinitely scalable. The program can take the current apparent magnification and the pixel density of the display device (printer, monitor, whatever) and draw the best possible depiction of that mathematical concept.

Since the image values are just the mathematical concepts, you can extract them from the context of drawing on the screen and use them to compute other mathematical results. If you have two lines segments, for instance, it's relatively easy to tell if they intersect. The most naive implementation of LOS checking (ground-level only, everything's an obstacle) would be:

for each obstacle-blob in all-obstacles {
    if obstacle-blob.intersects( los-line ) {
        los-blocked = true;
        break;
    }
}

You could make this more efficient by only checking obstacle-blobs that are near the los-line, but that is purely a performance improvement. If you check them all you get the right answer too. Writing the "intersects()" method is going to be the heart of the algorithm. It will be pure data and code, i.e. there should be no reference to a graphics object.

Would such areas be created as part of the board making process or would it require additional work at the graphic stage? And would the "different artistic schemes" you wrote of produce better maps? If so, then it may be worth doing even if it doesn't change the los scheme that much.

Instead of painting a bunch of dots in a grid, drawing with a vector graphics program creates a bunch of mathematical descriptions. The artist usually won't manipulate the mathematical descriptions directly (although you can, and this can be very helpful at times); the artist will typically use a wsiwyg program.

Different artistic schemes would allow woods, for example, to be different colors on different maps. For instance a pine forest in Norway could be drawn with a black-blue-green, while winter trees in the Ardennes could be brown-black.

I ask from a position of great ignorance about vector graphics and not from any reluctance to embrace them if the return is worth the investment. I simply don't know a damn thing. And better graphic boards may very well be worth rejigging the los engine for.

I have attached a .svg file (zipped because github won't take one raw). Download it, unzip it, then open it with a text editor. I drew a single rectangle in it. If you look in the text you will see a bunch of header stuff and then a <rect> tag. That is not something you will see in raster graphics. The object is a mathematical description of what to draw, not a grid with pixels of different colors on it.

You can also view it in a .svg program, e.g. inkscape. You will see that it has a fill color, a border color, and a dashed border style that are remnants of something I was working on. You can also see these features in the attributes of the <rect> tag in the text editor. If you are using inkscape you should be able to click on the rectangle and move it. If you select the rectangle tool and select it, you should see grab points to resize it.

Note inkscape defaults to A4 paper size for its images, so if you print my beautiful image it may not work quite as expected.

drawing.svg.zip

jrvjrv commented 4 years ago

I just remembered that gimp will open .svg files too, so if you don't want to install inkscape try gimp. It doesn't have vector graphics tools, so you can't edit it as a vector graphics file, but it will display the image I drew.

bkemp01 commented 4 years ago

most browsers will open/display SVG files also

On Wed, Mar 25, 2020 at 5:01 PM jrvjrv notifications@github.com wrote:

I just remembered that gimp will open .svg files too, so if you don't want to install inkscape try gimp. It doesn't have vector graphics tools, so you can't edit it as a vector graphics file, but it will display the image I drew.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-604085288, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAT6ZT7MGQPSS5H33BRLT3RJJWLFANCNFSM4LRCVSMQ .

derimmer commented 5 months ago

@GordonMolek @apbills @tqrtuomo

This thread has been dormant for a while but I am hoping to work some life back into it as we are taking the plunge and using .svg graphics in VASL now. Version 668 which releases in April will contain about 15 .svg files as part of the implementation of class ID info on the broken side of MMC counters (all praise to @GordonMolek for his work on that). Grab the beta5 from the Releases page on Github to get a sneak peek.

It may be that some others have slipped in when I was not paying close attention or are being used in extensions.

@tqrtuomo have you done any work with .svg file in map-making?

What I don't see happening is a whole scale conversion effort to replace all vasl images (8000+). I think we are open to opportunities where the benefits out-weigh the costs - and that means AFV images I think for starters.

Not looking to have a grand plan here. More a concensus on a strategy that gets implemented as and when.

Comments welcome.

BigAl737 commented 5 months ago

I would love to see VASL converted in whole to SVG. However, as stated in the OP, there's drawbacks. As you say Doug, no way are we going to convert 8000+ images. But even setting the SVG format as standard from this point forward has it's issues. The biggest I see is easily visible in the following screenshot.

These are both SVG images viewed at 150%. One is simply rotated one facing. The left one shows all the advantages of SVG. However, as soon as you rotate it, VASSAL seems to convert it to a raster version, which negates any vector benefit. As I recall, VASSAL 4.0 will fix this.

IMHO, when VASSAL 4.0 comes online, the age of raster is over. The time of the vector has come.

This is not the end. It is not even the beginning of the end. But it is perhaps, the end of the beginning.

(You get extra points citing the sources of my paraphrases)

(The images are taken from the BFP extension)

zgrose commented 5 months ago

It's worth bearing in mind, IMO, that part of the perceived issue is probably in the VASSAL rendering engine, not the file that is being rendered. For example, just grabbing the PNG in the post above, if I drop that into Roll20, it rotates and zooms just fine.

The biggest SVG benefit that I see is that it's easier to generate the images in the first place (composing them from re-usable bits). Once, for instance, you have an American Squad and HalfSquad SVG definition, you're just copy/pasting over and over and dropping in the other bits. So just being pedantic, it's not 8000+ images, its 8000+ counter definitions with 4000 (number pulled from a**) image components.

GordonMolek commented 5 months ago

That's an interesting point that will need to be decided upon. For the example case of a vehicle, is it better to have the turret type (e.g., "fast", "slow", "restricted slow", "1 man") included in the SVG file of each applicable vehicle or to composite the vehicle image within the VASL piece definition by including the appropriate turret type as a layer/level in the piece definition.

On Wed, Jan 24, 2024 at 7:49 PM Zoltan Grose @.***> wrote:

It's worth bearing in mind, IMO, that part of the perceived issue is probably in the VASSAL rendering engine, not the file that is being rendered. For example, just grabbing the PNG in the post above, if I drop that into Roll20, it rotates and zooms just fine. Screenshot.2024-01-24.194113.png (view on web) https://github.com/vasl-developers/vasl/assets/5044847/d765321a-445d-499c-bb71-8e3233da6976

The biggest SVG benefit that I see is that it's easier to generate the images in the first place (composing them from re-usable bits). Once, for instance, you have an American Squad and HalfSquad SVG definition, you're just copy/pasting over and over and dropping in the other bits. So just being pedantic, it's not 8000+ images, its 8000+ counter definitions with 4000 (number pulled from a**) image components.

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1909211551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUWPIUVUNDAB22TUUALYQG2Y7AVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJQHEZDCMJVGUYQ . You are receiving this because you were mentioned.Message ID: @.***>

zgrose commented 5 months ago

Without seeing the VASSAL 4 counter definition structure, I'm gonna go out on a limb and say that composition in SVG is going to be WAY less work than setting up 20 layers in a counter. Just a hunch, though.

uckelman commented 5 months ago

It's worth bearing in mind, IMO, that part of the perceived issue is probably in the VASSAL rendering engine

This. The reason SVG gets blurred in Vassal 3 when it's rotated is that there is no way currently to pass inward through the trait stack the accumulated amount of rotation. The SVG renderer is perfectly capable of rendering rotated images, but it needs to be told the angle in order to do that.

If this is a thing you want in V3, I could offer advice for doing it but you'd have to find someone else to do the work. I'm no longer working on any V3 issues myself---only on managing V3 releases and doing things which move V4 forward now.

As for whether this work on V3 is worth doing, I can assure you that you'd have ample time to benefit from it after it's complete. V3 will be in use for quite a while yet.

GordonMolek commented 5 months ago

I don't know what the timeline is for Vassal 4 but I can't imagine we'd be rushing to get anything out before then given the scope of even a minimal start on this conversion would entail.

On Thu, Jan 25, 2024 at 5:50 AM Joel Uckelman @.***> wrote:

It's worth bearing in mind, IMO, that part of the perceived issue is probably in the VASSAL rendering engine

This. The reason SVG gets blurred in Vassal 3 when it's rotated is that there is no way currently to pass inward through the trait stack the accumulated amount of rotation. The SVG renderer is perfectly capable of rendering rotated images, but it needs to be told the angle in order to do that.

If this is a thing you want in V3, I could offer advice for doing it but you'd have to find someone else to do the work. I'm no longer working on any V3 issues myself---only on managing V3 releases and things which move V4 forward now.

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1910021854, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUU3CYWUEJKBW7QDGP3YQJBHRAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGAYDEMJYGU2A . You are receiving this because you were mentioned.Message ID: @.***>

uckelman commented 5 months ago

is it better to have the turret type (e.g., "fast", "slow", "restricted slow", "1 man") included in the SVG file of each applicable vehicle or to composite the vehicle image within the VASL piece definition by including the appropriate turret type as a layer/level in the piece definition.

Put all the components in a <defs> section of one SVG file. Refer to them with <use> elements in the piece image files. Don't repeat anything. This way, if you need to update one of the components, it's automatically updated in all piece image files without any work.

Even better is to generate the SVG for each piece from a spreadsheet. This is what I did for the pieces in the module for The Longest Day. There's something like 4k piece faces; it's foolish to create that many by hand when they're composed from reusable parts.

GordonMolek commented 5 months ago

I agree in principle but some special handling might be required (or we may need to simplify what's displayed on some of the counters). The issue is the diversity of information that can be displayed across the various types of vehicle counters (for instance). These sometimes shift items around from counter to counter. As an example, the "Rate of Fire" box isn't always at the same location on every counter that includes it. If there's a way to handle modifications like that in the spreadsheet approach you suggest then that would be awesome. We could develop a series of alternative offsets for the various different situations.

Great discussion.

On Thu, Jan 25, 2024 at 6:16 AM Joel Uckelman @.***> wrote:

is it better to have the turret type (e.g., "fast", "slow", "restricted slow", "1 man") included in the SVG file of each applicable vehicle or to composite the vehicle image within the VASL piece definition by including the appropriate turret type as a layer/level in the piece definition.

Put all the components in a section of one SVG file. Refer to them with elements in the piece image files. Don't repeat anything. This way, if you need to update one of the components, it's automatically updated in all piece image files without any work.

Even better is to generate the SVG for each piece from a spreadsheet. This is what I did for the pieces in the module for The Longest Day. There's something like 4k piece faces; it's foolish to create that many by hand when they're composed from reusable parts.

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1910087417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUXBZZBF4N6ZLW2PCUDYQJEJXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGAYDQNZUGE3Q . You are receiving this because you were mentioned.Message ID: @.***>

uckelman commented 5 months ago

I don't know what the timeline is for Vassal 4 but I can't imagine we'd be rushing to get anything out before then given the scope of even a minimal start on this conversion would entail.

I wouldn't base your planning for using SVG for pieces on guesses about when V4 will be available. Produce a sound plan for generating the SVG and execute it; the SVG will be useful no matter when it's ready.

derimmer commented 5 months ago

I don't know what the timeline is for Vassal 4 but I can't imagine we'd be rushing to get anything out before then given the scope of even a minimal start on this conversion would entail.

I wouldn't base your planning for using SVG for pieces on guesses about when V4 will be available. Produce a sound plan for generating the SVG and execute it; the SVG will be useful no matter when it's ready.

Yes I like the sound of that.

To my mind, a good plan derives from some experimentation. I would like us to test out some ideas around the issues being raised upthread and use the learning g from that to formulate a plan. I can see some places were a prototype approach would work very well and others where a touch-each-counter might be necessary. Plus we need to think about non-counter elements: boards and overlays.

GordonMolek commented 5 months ago

Thinking about whether or not it makes any sense to have the asterisks that are used to remind the player to check the notes on the back of the (physical) counters on the VASL counters at all. Given that the VASL counter are blank except for the wreck depiction. It would simplify compositing pieces and free up additional real estate on the front sides of the counters.

On Thu, Jan 25, 2024 at 8:36 AM Doug Rimmer @.***> wrote:

I don't know what the timeline is for Vassal 4 but I can't imagine we'd be rushing to get anything out before then given the scope of even a minimal start on this conversion would entail.

I wouldn't base your planning for using SVG for pieces on guesses about when V4 will be available. Produce a sound plan for generating the SVG and execute it; the SVG will be useful no matter when it's ready.

Yes I like the sound of that.

To my mind, a good plan derives from some experimentation. I would like us to test out some ideas around the issues being raised upthread and use the learning g from that to formulate a plan. I can see some places were a prototype approach would work very well and others where a touch-each-counter might be necessary. Plus we need to think about non-counter elements: boards and overlays.

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1910337739, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUUXAEXD543EA27FYA3YQJUWHAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGAZTGNZXGM4Q . You are receiving this because you were mentioned.Message ID: @.***>

apbills commented 5 months ago

I think they are still potentially valuable to indicate something is in the Show Info text. I do understand the severe lack of real estate on counters. With .svg text it should be fairly crisp at a smaller size (maybe) but who knows.

From: GordonMolek @.> Sent: Thursday, January 25, 2024 6:19 PM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

Thinking about whether or not it makes any sense to have the asterisks that are used to remind the player to check the notes on the back of the (physical) counters on the VASL counters at all. Given that the VASL counter are blank except for the wreck depiction. It would simplify compositing pieces and free up additional real estate on the front sides of the counters.

On Thu, Jan 25, 2024 at 8:36 AM Doug Rimmer @.***> wrote:

I don't know what the timeline is for Vassal 4 but I can't imagine we'd be rushing to get anything out before then given the scope of even a minimal start on this conversion would entail.

I wouldn't base your planning for using SVG for pieces on guesses about when V4 will be available. Produce a sound plan for generating the SVG and execute it; the SVG will be useful no matter when it's ready.

Yes I like the sound of that.

To my mind, a good plan derives from some experimentation. I would like us to test out some ideas around the issues being raised upthread and use the learning g from that to formulate a plan. I can see some places were a prototype approach would work very well and others where a touch-each-counter might be necessary. Plus we need to think about non-counter elements: boards and overlays.

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1910337739, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUUXAEXD543EA27FYA3YQJUWHAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGAZTGNZXGM4Q . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHubhttps://github.com/vasl-developers/vasl/issues/627#issuecomment-1911209237, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3X3PPRT3BXPUFD5FSJHKSLYQLZBBAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGEZDAOJSGM3Q. You are receiving this because you were mentioned.Message ID: @.***>

GordonMolek commented 5 months ago

Yeah, they probably are still necessary but I wonder if the "info" label could take their place.

On Thu, Jan 25, 2024 at 9:00 PM apbills @.***> wrote:

I think they are still potentially valuable to indicate something is in the Show Info text. I do understand the severe lack of real estate on counters. With .svg text it should be fairly crisp at a smaller size (maybe) but who knows.

From: GordonMolek @.> Sent: Thursday, January 25, 2024 6:19 PM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

Thinking about whether or not it makes any sense to have the asterisks that are used to remind the player to check the notes on the back of the (physical) counters on the VASL counters at all. Given that the VASL counter are blank except for the wreck depiction. It would simplify compositing pieces and free up additional real estate on the front sides of the counters.

On Thu, Jan 25, 2024 at 8:36 AM Doug Rimmer @.***> wrote:

I don't know what the timeline is for Vassal 4 but I can't imagine we'd be rushing to get anything out before then given the scope of even a minimal start on this conversion would entail.

I wouldn't base your planning for using SVG for pieces on guesses about when V4 will be available. Produce a sound plan for generating the SVG and execute it; the SVG will be useful no matter when it's ready.

Yes I like the sound of that.

To my mind, a good plan derives from some experimentation. I would like us to test out some ideas around the issues being raised upthread and use the learning g from that to formulate a plan. I can see some places were a prototype approach would work very well and others where a touch-each-counter might be necessary. Plus we need to think about non-counter elements: boards and overlays.

— Reply to this email directly, view it on GitHub < https://github.com/vasl-developers/vasl/issues/627#issuecomment-1910337739>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AYLTFUUXAEXD543EA27FYA3YQJUWHAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGAZTGNZXGM4Q>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub< https://github.com/vasl-developers/vasl/issues/627#issuecomment-1911209237>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/A3X3PPRT3BXPUFD5FSJHKSLYQLZBBAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGEZDAOJSGM3Q>.

You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1911332044, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUTSASDEFCL5ISBJZCLYQML5FAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGEZTGMRQGQ2A . You are receiving this because you were mentioned.Message ID: @.***>

derimmer commented 5 months ago

I would prefer them to be gone (or at the very least be replaced by something else). I find the presence of an * in two places on a Gun/Vehicle counter (before the MA listing denoting important info on the flip side; after the MA listing denoting short Gun barrel - or is it the other way around) very confusing and often mistake the two. I don't think we need any symbol on the front which basically says see other side but if we do it should not be an asterisk.

apbills commented 5 months ago

I just noticed that the Russian M3A1 SC(a) counter has 3 different asterisks on its front, one after the 9PP, one before the AAMG MA label and one after the 6 AAMG number. That is overkill by far. One indicator of some sort is all that should be needed to go look at the Show Info text. The note regarding the 9PP is not even in the Show Info text since it is a long sentence. I guess at some point you have to just have the players actually read the vehicle notes to absorb all of the special aspects that come along with each vehicle in their OB.

From: Doug Rimmer @.> Sent: Friday, January 26, 2024 2:26 PM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

I would prefer them to be gone (or at the very least be replaced by something else). I find the presence of an * in two places on a Gun/Vehicle counter (before the MA listing denoting important info on the flip side; after the MA listing denoting short Gun barrel - or is it the other way around) very confusing and often mistake the two. I don't think we need any symbol on the front which basically says see other side but if we do it should not be an asterisk.

— Reply to this email directly, view it on GitHubhttps://github.com/vasl-developers/vasl/issues/627#issuecomment-1912652110, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3X3PPWLBRYIHBCMVAOLFVTYQQGMBAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGI3DKMRRGEYA. You are receiving this because you were mentioned.Message ID: @.***>

derimmer commented 5 months ago

@apbills agreed

GordonMolek commented 5 months ago

Yes, I agree that one indicator, TBD, that there are vehicle/gun notes that should be consulted would be enough. Maybe up in the upper left corner where the counter ID would normally be.

On Sun, Jan 28, 2024 at 1:29 AM Doug Rimmer @.***> wrote:

@apbills https://github.com/apbills agreed

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913485474, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUWFBUCH3O26RWSHGPDYQX44XAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM2DQNJUG42A . You are receiving this because you were mentioned.Message ID: @.***>

apbills commented 5 months ago

I know I have used that space to the right of the area reserved for the ground pressure indicator, which was fairly clear, for the SW indicator on the vehicles carrying PSK/BAZ. I also used the area directly below the side armor factor to put the “Sz” indicator for those German tanks with Schuerzen. As you can see I have been busy finding any free space for my added functionality. It is probably a good time to look at everything out there in the counter layouts to understand if anything else is using some of that free space. It may not be a problem to dual use the space given the only time a note indicator is needed is if something other than the normal notes (CS, Ammo, etc.) is desired, and even then maybe the level of “desire” comes into play.

You can pull a German SPW 251/10 counter and remove either an ATR or a PSK and see what is placed in that space now. You can also pull a German PzKfw IVH counter and activate the Schuerzen layer to see the text I added there. For the SW, that was just the space available for the text, for the Sz, since it was AF related it seemed that was the appropriate spot for the indicator.

From: GordonMolek @.> Sent: Sunday, January 28, 2024 4:14 AM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

Yes, I agree that one indicator, TBD, that there are vehicle/gun notes that should be consulted would be enough. Maybe up in the upper left corner where the counter ID would normally be.

On Sun, Jan 28, 2024 at 1:29 AM Doug Rimmer @.***> wrote:

@apbills https://github.com/apbills agreed

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913485474, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUWFBUCH3O26RWSHGPDYQX44XAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM2DQNJUG42A . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHubhttps://github.com/vasl-developers/vasl/issues/627#issuecomment-1913543537, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3X3PPTNLT6IEGEKKLZRYNTYQYQHDAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM2TIMZVGM3Q. You are receiving this because you were mentioned.Message ID: @.***>

derimmer commented 5 months ago

@apbills wrote: "It is probably a good time to look at everything out there in the counter layouts to understand if anything else is using some of that free space."

Agreed. The logical place to start of course is with vehicle counters. I don't think we have any counters were space utilization is an issue.

A related issue is the one about restructuring the AFV popup menu into a more coherent order. Having a logic to our placement of what info goes where might give us some thoughts about what stuff should be grouped together and sorted on the menu.

My preference is to start with the the counter image. And use our resolution of those issues to set the table for a discussion about the menu.

If we agree then I will create a discussion issue about AFV Counter Images and Information Placement.

@apbills one thing that occured to me as I read your last post is that it might be worth checking to see if any of the bad things images that appear over the counter (as opposed to around the edges) obscure any of the space you have been using.

It might also be worth talking about the use of traits that I have not see used much if at all in VASL (Action Button, Property Sheet).

GordonMolek commented 5 months ago

Speaking as a total newbie., we may also want to think "outside the counter" to see if there's some other method for alerting the player to "check the (multi-applicable) vehicle notes" without taking up space on the face of the counter.

On Sun, Jan 28, 2024 at 2:56 PM Doug Rimmer @.***> wrote:

@apbills https://github.com/apbills wrote: "It is probably a good time to look at everything out there in the counter layouts to understand if anything else is using some of that free space."

Agreed. The logical place to start of course is with vehicle counters. I don't think we have any counters were space utilization is an issue.

A related issue is the one about restructuring the AFV popup menu into a more coherent order. Having a logic to our placement of what info goes where might give us some thoughts about what stuff should be grouped together and sorted on the menu.

My preference is to start with the the counter image. And use our resolution of those issues to set the table for a discussion about the menu.

If we agree then I will create a discussion issue about AFV Counter Images and Information Placement.

@apbills https://github.com/apbills one thing that occured to me as I read your last post is that it might be worth checking to see if any of the bad things images that appear over the counter (as opposed to around the edges) obscure any of the space you have been using.

It might also be worth talking about the use of traits that I have not see used much if at all in VASL (Action Button, Property Sheet).

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913719417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUS5LIMXIIOTZKXXN5LYQ23OXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TCOJUGE3Q . You are receiving this because you were mentioned.Message ID: @.***>

apbills commented 5 months ago

First off, opening a discussion on Github is probably a good idea. Thinking out of the box seems to work better in that kind of environment.

Second, as far as I know nothing else was in those spaces, however, I will recheck all of the “Bad things” overlays to see what I am missing or what is so rare I forgot it.

Third, I think something like new .svg images for “Bad things” could become a separate implementation task given it would be self-contained to just those items. Maybe I will be able to actually read the BMG, CMG and AAMG labels on them.

Fourth, I have created some counters using the Property Sheet trait, and it has some functionality although not as much directly applicable to ASL. I have used it for Notes along with the Invisible capabilities to give the player the capability to place hidden notes around the mapboard (I am working very large campaign game things) to help plan/execute the next phase or turn. Kind of like a reminder sheet. I will look into some of the other traits we do not normally see in ASL. There may be something else that we could put to use.

From: GordonMolek @.> Sent: Sunday, January 28, 2024 5:06 PM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

Speaking as a total newbie., we may also want to think "outside the counter" to see if there's some other method for alerting the player to "check the (multi-applicable) vehicle notes" without taking up space on the face of the counter.

On Sun, Jan 28, 2024 at 2:56 PM Doug Rimmer @.***> wrote:

@apbills https://github.com/apbills wrote: "It is probably a good time to look at everything out there in the counter layouts to understand if anything else is using some of that free space."

Agreed. The logical place to start of course is with vehicle counters. I don't think we have any counters were space utilization is an issue.

A related issue is the one about restructuring the AFV popup menu into a more coherent order. Having a logic to our placement of what info goes where might give us some thoughts about what stuff should be grouped together and sorted on the menu.

My preference is to start with the the counter image. And use our resolution of those issues to set the table for a discussion about the menu.

If we agree then I will create a discussion issue about AFV Counter Images and Information Placement.

@apbills https://github.com/apbills one thing that occured to me as I read your last post is that it might be worth checking to see if any of the bad things images that appear over the counter (as opposed to around the edges) obscure any of the space you have been using.

It might also be worth talking about the use of traits that I have not see used much if at all in VASL (Action Button, Property Sheet).

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913719417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUS5LIMXIIOTZKXXN5LYQ23OXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TCOJUGE3Q . You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHubhttps://github.com/vasl-developers/vasl/issues/627#issuecomment-1913751994, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3X3PPWFTNGGOS5WGAZUJBDYQ3KVRAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TKMJZHE2A. You are receiving this because you were mentioned.Message ID: @.***>

GordonMolek commented 4 months ago

I've been noodling around with compositing an AFV counter using a combination of external SVG assets and text fields. I've got this, which displays in a browser.

[image: image.png]

<image xlink:href="../../svg/gun_and_vehicle_assets/BaseLargeGerman.svg" x="0" y="0" height="60px" width="60px"> <image xlink:href="../../svg/gun_and_vehicle_assets/tt_slow.svg" x="2.5" y="2.5"> <image xlink:href="../../svg/gun_and_vehicle_assets/ma_88L.svg" x="1.8" y="44.3"> <image xlink:href="../../svg/gun_and_vehicle_assets/rof_1.svg" x="1.8" y="34"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_red_11.svg" x="45" y="18"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_red_superior.svg" x="45" y="18"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_black_8.svg" x="45" y="28"> <image xlink:href="../../svg/gun_and_vehicle_assets/mt_tracked.svg" x="35" y="1.8"> 12 3/5

But while VASSAL/VASL allows me to use the SVG file for a counter image it displays an empty counter. Any ideas what I'm doing wrong?

Thanks,

Gordon

On Sun, Jan 28, 2024 at 5:27 PM apbills @.***> wrote:

First off, opening a discussion on Github is probably a good idea. Thinking out of the box seems to work better in that kind of environment.

Second, as far as I know nothing else was in those spaces, however, I will recheck all of the “Bad things” overlays to see what I am missing or what is so rare I forgot it.

Third, I think something like new .svg images for “Bad things” could become a separate implementation task given it would be self-contained to just those items. Maybe I will be able to actually read the BMG, CMG and AAMG labels on them.

Fourth, I have created some counters using the Property Sheet trait, and it has some functionality although not as much directly applicable to ASL. I have used it for Notes along with the Invisible capabilities to give the player the capability to place hidden notes around the mapboard (I am working very large campaign game things) to help plan/execute the next phase or turn. Kind of like a reminder sheet. I will look into some of the other traits we do not normally see in ASL. There may be something else that we could put to use.

From: GordonMolek @.> Sent: Sunday, January 28, 2024 5:06 PM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

Speaking as a total newbie., we may also want to think "outside the counter" to see if there's some other method for alerting the player to "check the (multi-applicable) vehicle notes" without taking up space on the face of the counter.

On Sun, Jan 28, 2024 at 2:56 PM Doug Rimmer @.***> wrote:

@apbills https://github.com/apbills wrote: "It is probably a good time to look at everything out there in the counter layouts to understand if anything else is using some of that free space."

Agreed. The logical place to start of course is with vehicle counters. I don't think we have any counters were space utilization is an issue.

A related issue is the one about restructuring the AFV popup menu into a more coherent order. Having a logic to our placement of what info goes where might give us some thoughts about what stuff should be grouped together and sorted on the menu.

My preference is to start with the the counter image. And use our resolution of those issues to set the table for a discussion about the menu.

If we agree then I will create a discussion issue about AFV Counter Images and Information Placement.

@apbills https://github.com/apbills one thing that occured to me as I read your last post is that it might be worth checking to see if any of the bad things images that appear over the counter (as opposed to around the edges) obscure any of the space you have been using.

It might also be worth talking about the use of traits that I have not see used much if at all in VASL (Action Button, Property Sheet).

— Reply to this email directly, view it on GitHub < https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913719417>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AYLTFUS5LIMXIIOTZKXXN5LYQ23OXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TCOJUGE3Q>

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub< https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913751994>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/A3X3PPWFTNGGOS5WGAZUJBDYQ3KVRAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TKMJZHE2A>.

You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913757931, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFURZHIHJKKW2TPCAMVTYQ3NF3AVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TKNZZGMYQ . You are receiving this because you were mentioned.Message ID: @.***>

apbills commented 4 months ago

Gordon,

I am not sure how VASL resolves all of those links. They have relative addresses, and I am not sure how it will find them.

Alan

From: GordonMolek @.> Sent: Monday, February 19, 2024 3:52 PM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

I've been noodling around with compositing an AFV counter using a combination of external SVG assets and text fields. I've got this, which displays in a browser.

[image: image.png]

<image xlink:href="../../svg/gun_and_vehicle_assets/BaseLargeGerman.svg" x="0" y="0" height="60px" width="60px"> <image xlink:href="../../svg/gun_and_vehicle_assets/tt_slow.svg" x="2.5" y="2.5"> <image xlink:href="../../svg/gun_and_vehicle_assets/ma_88L.svg" x="1.8" y="44.3"> <image xlink:href="../../svg/gun_and_vehicle_assets/rof_1.svg" x="1.8" y="34"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_red_11.svg" x="45" y="18"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_red_superior.svg" x="45" y="18"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_black_8.svg" x="45" y="28"> <image xlink:href="../../svg/gun_and_vehicle_assets/mt_tracked.svg" x="35" y="1.8"> 12 3/5

But while VASSAL/VASL allows me to use the SVG file for a counter image it displays an empty counter. Any ideas what I'm doing wrong?

Thanks,

Gordon

On Sun, Jan 28, 2024 at 5:27 PM apbills @.<mailto:@.>> wrote:

First off, opening a discussion on Github is probably a good idea. Thinking out of the box seems to work better in that kind of environment.

Second, as far as I know nothing else was in those spaces, however, I will recheck all of the “Bad things” overlays to see what I am missing or what is so rare I forgot it.

Third, I think something like new .svg images for “Bad things” could become a separate implementation task given it would be self-contained to just those items. Maybe I will be able to actually read the BMG, CMG and AAMG labels on them.

Fourth, I have created some counters using the Property Sheet trait, and it has some functionality although not as much directly applicable to ASL. I have used it for Notes along with the Invisible capabilities to give the player the capability to place hidden notes around the mapboard (I am working very large campaign game things) to help plan/execute the next phase or turn. Kind of like a reminder sheet. I will look into some of the other traits we do not normally see in ASL. There may be something else that we could put to use.

From: GordonMolek @.<mailto:@.>> Sent: Sunday, January 28, 2024 5:06 PM To: vasl-developers/vasl @.<mailto:@.>> Cc: apbills @.<mailto:@.>>; Mention @.<mailto:@.>> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

Speaking as a total newbie., we may also want to think "outside the counter" to see if there's some other method for alerting the player to "check the (multi-applicable) vehicle notes" without taking up space on the face of the counter.

On Sun, Jan 28, 2024 at 2:56 PM Doug Rimmer @.<mailto:@.>> wrote:

@apbills https://github.com/apbills wrote: "It is probably a good time to look at everything out there in the counter layouts to understand if anything else is using some of that free space."

Agreed. The logical place to start of course is with vehicle counters. I don't think we have any counters were space utilization is an issue.

A related issue is the one about restructuring the AFV popup menu into a more coherent order. Having a logic to our placement of what info goes where might give us some thoughts about what stuff should be grouped together and sorted on the menu.

My preference is to start with the the counter image. And use our resolution of those issues to set the table for a discussion about the menu.

If we agree then I will create a discussion issue about AFV Counter Images and Information Placement.

@apbills https://github.com/apbills one thing that occured to me as I read your last post is that it might be worth checking to see if any of the bad things images that appear over the counter (as opposed to around the edges) obscure any of the space you have been using.

It might also be worth talking about the use of traits that I have not see used much if at all in VASL (Action Button, Property Sheet).

— Reply to this email directly, view it on GitHub < https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913719417>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AYLTFUS5LIMXIIOTZKXXN5LYQ23OXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TCOJUGE3Q>

. You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHub< https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913751994>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/A3X3PPWFTNGGOS5WGAZUJBDYQ3KVRAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TKMJZHE2A>.

You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913757931, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFURZHIHJKKW2TPCAMVTYQ3NF3AVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TKNZZGMYQ . You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHubhttps://github.com/vasl-developers/vasl/issues/627#issuecomment-1953198275, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3X3PPVN34CFNZUIPWN5Q33YUPCQDAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGMYTSOBSG42Q. You are receiving this because you were mentioned.Message ID: @.**@.>>

GordonMolek commented 4 months ago

Looking at earlier debug traces when I was causing VASSAL/VASL to crash it seemed to handle the links properly. That is to say it was appending the relative paths to the base "images" path. That seems to be what Microsoft Edge does which renders properly.

On Mon, Feb 19, 2024 at 7:39 PM apbills @.***> wrote:

Gordon,

I am not sure how VASL resolves all of those links. They have relative addresses, and I am not sure how it will find them.

Alan

From: GordonMolek @.> Sent: Monday, February 19, 2024 3:52 PM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

I've been noodling around with compositing an AFV counter using a combination of external SVG assets and text fields. I've got this, which displays in a browser.

[image: image.png]

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 60 60">

<image xlink:href="../../svg/gun_and_vehicle_assets/BaseLargeGerman.svg" x="0" y="0" height="60px" width="60px"> <image xlink:href="../../svg/gun_and_vehicle_assets/tt_slow.svg" x="2.5" y="2.5"> <image xlink:href="../../svg/gun_and_vehicle_assets/ma_88L.svg" x="1.8" y="44.3"> <image xlink:href="../../svg/gun_and_vehicle_assets/rof_1.svg" x="1.8" y="34"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_red_11.svg" x="45" y="18"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_red_superior.svg" x="45" y="18"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_black_8.svg" x="45" y="28"> <image xlink:href="../../svg/gun_and_vehicle_assets/mt_tracked.svg" x="35" y="1.8"> 12 3/5

But while VASSAL/VASL allows me to use the SVG file for a counter image it displays an empty counter. Any ideas what I'm doing wrong?

Thanks,

Gordon

On Sun, Jan 28, 2024 at 5:27 PM apbills @.<mailto:@.>> wrote:

First off, opening a discussion on Github is probably a good idea. Thinking out of the box seems to work better in that kind of environment.

Second, as far as I know nothing else was in those spaces, however, I will recheck all of the “Bad things” overlays to see what I am missing or what is so rare I forgot it.

Third, I think something like new .svg images for “Bad things” could become a separate implementation task given it would be self-contained to just those items. Maybe I will be able to actually read the BMG, CMG and AAMG labels on them.

Fourth, I have created some counters using the Property Sheet trait, and it has some functionality although not as much directly applicable to ASL. I have used it for Notes along with the Invisible capabilities to give the player the capability to place hidden notes around the mapboard (I am working very large campaign game things) to help plan/execute the next phase or turn. Kind of like a reminder sheet. I will look into some of the other traits we do not normally see in ASL. There may be something else that we could put to use.

From: GordonMolek @.<mailto:@.>> Sent: Sunday, January 28, 2024 5:06 PM To: vasl-developers/vasl @.<mailto:@.>> Cc: apbills @.<mailto:@.>>; Mention @.<mailto:@.>> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

Speaking as a total newbie., we may also want to think "outside the counter" to see if there's some other method for alerting the player to "check the (multi-applicable) vehicle notes" without taking up space on the face of the counter.

On Sun, Jan 28, 2024 at 2:56 PM Doug Rimmer @.<mailto:@.>>

wrote:

@apbills https://github.com/apbills wrote: "It is probably a good time to look at everything out there in the counter layouts to understand if anything else is using some of that free space."

Agreed. The logical place to start of course is with vehicle counters. I don't think we have any counters were space utilization is an issue.

A related issue is the one about restructuring the AFV popup menu into a more coherent order. Having a logic to our placement of what info goes where might give us some thoughts about what stuff should be grouped together and sorted on the menu.

My preference is to start with the the counter image. And use our resolution of those issues to set the table for a discussion about the menu.

If we agree then I will create a discussion issue about AFV Counter Images and Information Placement.

@apbills https://github.com/apbills one thing that occured to me as I read your last post is that it might be worth checking to see if any of the bad things images that appear over the counter (as opposed to around the edges) obscure any of the space you have been using.

It might also be worth talking about the use of traits that I have not see used much if at all in VASL (Action Button, Property Sheet).

— Reply to this email directly, view it on GitHub <

https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913719417>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AYLTFUS5LIMXIIOTZKXXN5LYQ23OXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TCOJUGE3Q>

. You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHub<

https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913751994>,

or unsubscribe<

https://github.com/notifications/unsubscribe-auth/A3X3PPWFTNGGOS5WGAZUJBDYQ3KVRAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TKMJZHE2A>.

You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHub < https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913757931>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AYLTFURZHIHJKKW2TPCAMVTYQ3NF3AVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TKNZZGMYQ>

. You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHub< https://github.com/vasl-developers/vasl/issues/627#issuecomment-1953198275>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/A3X3PPVN34CFNZUIPWN5Q33YUPCQDAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGMYTSOBSG42Q>.

You are receiving this because you were mentioned.Message ID: @.**@.>>

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1953353774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUQWHMKWQZA4OPCAFU3YUP5FLAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGMZTKMZXG42A . You are receiving this because you were mentioned.Message ID: @.***>

GordonMolek commented 4 months ago

I tried an experiment where I commented out all the image references and the text fields display on an otherwise transparent counter.

On Tue, Feb 20, 2024 at 4:45 AM Gordon Molek @.***> wrote:

Looking at earlier debug traces when I was causing VASSAL/VASL to crash it seemed to handle the links properly. That is to say it was appending the relative paths to the base "images" path. That seems to be what Microsoft Edge does which renders properly.

On Mon, Feb 19, 2024 at 7:39 PM apbills @.***> wrote:

Gordon,

I am not sure how VASL resolves all of those links. They have relative addresses, and I am not sure how it will find them.

Alan

From: GordonMolek @.> Sent: Monday, February 19, 2024 3:52 PM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

I've been noodling around with compositing an AFV counter using a combination of external SVG assets and text fields. I've got this, which displays in a browser.

[image: image.png]

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 60 60">

<image xlink:href="../../svg/gun_and_vehicle_assets/BaseLargeGerman.svg" x="0" y="0" height="60px" width="60px"> <image xlink:href="../../svg/gun_and_vehicle_assets/tt_slow.svg" x="2.5" y="2.5"> <image xlink:href="../../svg/gun_and_vehicle_assets/ma_88L.svg" x="1.8" y="44.3"> <image xlink:href="../../svg/gun_and_vehicle_assets/rof_1.svg" x="1.8" y="34"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_red_11.svg" x="45" y="18"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_red_superior.svg" x="45" y="18"> <image xlink:href="../../svg/gun_and_vehicle_assets/ar_black_8.svg" x="45" y="28"> <image xlink:href="../../svg/gun_and_vehicle_assets/mt_tracked.svg" x="35" y="1.8"> 12 3/5

But while VASSAL/VASL allows me to use the SVG file for a counter image it displays an empty counter. Any ideas what I'm doing wrong?

Thanks,

Gordon

On Sun, Jan 28, 2024 at 5:27 PM apbills @.<mailto:@.>> wrote:

First off, opening a discussion on Github is probably a good idea. Thinking out of the box seems to work better in that kind of environment.

Second, as far as I know nothing else was in those spaces, however, I will recheck all of the “Bad things” overlays to see what I am missing or what is so rare I forgot it.

Third, I think something like new .svg images for “Bad things” could become a separate implementation task given it would be self-contained to just those items. Maybe I will be able to actually read the BMG, CMG and AAMG labels on them.

Fourth, I have created some counters using the Property Sheet trait, and it has some functionality although not as much directly applicable to ASL. I have used it for Notes along with the Invisible capabilities to give the player the capability to place hidden notes around the mapboard (I am working very large campaign game things) to help plan/execute the next phase or turn. Kind of like a reminder sheet. I will look into some of the other traits we do not normally see in ASL. There may be something else that we could put to use.

From: GordonMolek @.<mailto:@.>> Sent: Sunday, January 28, 2024 5:06 PM To: vasl-developers/vasl @.<mailto:@.>> Cc: apbills @.<mailto:@.>>; Mention @.<mailto:@.>> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

Speaking as a total newbie., we may also want to think "outside the counter" to see if there's some other method for alerting the player to "check the (multi-applicable) vehicle notes" without taking up space on the face of the counter.

On Sun, Jan 28, 2024 at 2:56 PM Doug Rimmer @.<mailto:@.>>

wrote:

@apbills https://github.com/apbills wrote: "It is probably a good time to look at everything out there in the counter layouts to understand if anything else is using some of that free space."

Agreed. The logical place to start of course is with vehicle counters. I don't think we have any counters were space utilization is an issue.

A related issue is the one about restructuring the AFV popup menu into a more coherent order. Having a logic to our placement of what info goes where might give us some thoughts about what stuff should be grouped together and sorted on the menu.

My preference is to start with the the counter image. And use our resolution of those issues to set the table for a discussion about the menu.

If we agree then I will create a discussion issue about AFV Counter Images and Information Placement.

@apbills https://github.com/apbills one thing that occured to me as I read your last post is that it might be worth checking to see if any of the bad things images that appear over the counter (as opposed to around the edges) obscure any of the space you have been using.

It might also be worth talking about the use of traits that I have not see used much if at all in VASL (Action Button, Property Sheet).

— Reply to this email directly, view it on GitHub <

https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913719417>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AYLTFUS5LIMXIIOTZKXXN5LYQ23OXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TCOJUGE3Q>

. You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHub<

https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913751994>,

or unsubscribe<

https://github.com/notifications/unsubscribe-auth/A3X3PPWFTNGGOS5WGAZUJBDYQ3KVRAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TKMJZHE2A>.

You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHub < https://github.com/vasl-developers/vasl/issues/627#issuecomment-1913757931>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AYLTFURZHIHJKKW2TPCAMVTYQ3NF3AVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGM3TKNZZGMYQ>

. You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHub< https://github.com/vasl-developers/vasl/issues/627#issuecomment-1953198275>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/A3X3PPVN34CFNZUIPWN5Q33YUPCQDAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGMYTSOBSG42Q>.

You are receiving this because you were mentioned.Message ID: @.**@.>>

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1953353774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUQWHMKWQZA4OPCAFU3YUP5FLAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGMZTKMZXG42A . You are receiving this because you were mentioned.Message ID: @.***>

derimmer commented 4 months ago

Does that suggest an error in the html used to display the image? Perhaps try bringing back one image ref and see if you can make it work. I am no expert on html, graphics, etc so I am reluctant to provide much advice.

GordonMolek commented 4 months ago

Yes, I just tried that. I'm working through the individual references one at a time to see if there's a problematic one. So far I've brought the base counter graphic back in and it is working.

On Tue, Feb 20, 2024 at 6:30 AM Doug Rimmer @.***> wrote:

Does that suggest an error in the html used to display the image? Perhaps try bringing back one image ref and see if you can make it work. I am no expert on html, graphics, etc so I am reluctant to provide much advice.

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1954115875, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUS66E4DD3CP3HVSFRDYUSJOXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGQYTCNJYG42Q . You are receiving this because you were mentioned.Message ID: @.***>

apbills commented 4 months ago

I am also not literate with svgs and images. This is the svg file from the TLD module for a single counter. It appears to use symbols, which are in the actual module, for all the counter unit types (boxes with infantry/armor/recon type symbols). I thought it might help me understand how it brought in images.

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="50" height="50">

12ss 3 III/26 7 7 8

From: Doug Rimmer @.> Sent: Tuesday, February 20, 2024 6:31 AM To: vasl-developers/vasl @.> Cc: apbills @.>; Mention @.> Subject: Re: [vasl-developers/vasl] Using SVG for VASL Discussion (#627)

Does that suggest an error in the html used to display the image? Perhaps try bringing back one image ref and see if you can make it work. I am no expert on html, graphics, etc so I am reluctant to provide much advice.

— Reply to this email directly, view it on GitHubhttps://github.com/vasl-developers/vasl/issues/627#issuecomment-1954115875, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3X3PPRXW6KNQSGWT43VXA3YUSJOXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGQYTCNJYG42Q. You are receiving this because you were mentioned.Message ID: @.***>

derimmer commented 4 months ago

Flagging something for future reference . . . .

Your effort to access and display images from outside of VASL reminded me of a discussion in another time and place about using JavaFX within the VASL module.

Amongst other uses, it might well have some helpful application to what you are trying to do. My first tinkering to try and make it work within VASL did not succeed but it should be worth trying again.

I leave it here just as a reminder.

GordonMolek commented 4 months ago

Having experimented with prototyping a 5/8 inch counter using SVG one question I have is what size/resolution should the new SVG-based artwork be? I realize that being vector based the whole idea of a 60 x 60 pixel counter (as are the current counters) doesn't make sense per se. But it would certainly make it easier to create a lot of the graphical assets on a known sized base and then scale everything appropriately for in-game use. Does anyone have any thoughts on this or am I overthinking the situation? For example we could adopt a 300dpi or 600dpi 5/8 inch x 5/8 inch image for the counter size or some other size and it shouldn't affect the overall size of the SVG files themselves.

On Tue, Feb 20, 2024 at 6:49 AM Doug Rimmer @.***> wrote:

Flagging something for future reference . . . .

Your effort to access and display images from outside of VASL reminded me of a discussion in another time and place about using JavaFX within the VASL module.

Amongst other uses, it might well have some helpful application to what you are trying to do. My first tinkering to try and make it work within VASL did not succeed but it should be worth trying again.

I leave it here just as a reminder.

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1954149542, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUTYPEBI4KUX7LMW63DYUSLWXAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGQYTIOJVGQZA . You are receiving this because you were mentioned.Message ID: @.***>

zgrose commented 4 months ago

Fairly sure DPI is a rendering concern, not an SVG concern.

GordonMolek commented 4 months ago

Correct, but I think it matters for the ease of laying out all the assets in their correct sizes and locations.

On Tue, Feb 20, 2024 at 9:50 PM Zoltan Grose @.***> wrote:

Fairly sure DPI is a rendering concern, not an SVG concern.

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1955837995, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUUT3VZQASK5R7C3YL3YUVVH3AVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGU4DGNZZHE2Q . You are receiving this because you were mentioned.Message ID: @.***>

derimmer commented 4 months ago

I don't have my head around the notion of vector graphics at all so my comments are somewhat guesswork.

@GordonMolek you wrote: " it would certainly make it easier to create a lot of the graphical assets on a known sized base and then scale everything appropriately for in-game use."

That makes sense to me.

Despite issues with the 5/8" counters hanging over the hexsides, I am not in favour of changing the "size" (as it appears on the map, relative to the map) of the counters from their current ratio. We are working on separate capability to change the size of the counters relative to the map (ie the deluxe hexes look) but that is a separate feature to be built off of the norm - which is the current ratio counter to map size. Does that make any sense?

Would SVG graphics help us with this desired functionality of being able to change that ratio - in particular being able to make the counters be smaller relative to the map?

GordonMolek commented 4 months ago

SVG SHOULD be the answer to all your counter scaling prayers.

On Wed, Feb 21, 2024 at 7:58 AM Doug Rimmer @.***> wrote:

I don't have my head around the notion of vector graphics at all so my comments are somewhat guesswork.

@GordonMolek https://github.com/GordonMolek you wrote: " it would certainly make it easier to create a lot of the graphical assets on a known sized base and then scale everything appropriately for in-game use."

That makes sense to me.

Despite issues with the 5/8" counters hanging over the hexsides, I am not in favour of changing the "size" (as it appears on the map, relative to the map) of the counters from their current ratio. We are working on separate capability to change the size of the counters relative to the map (ie the deluxe hexes look) but that is a separate feature to be built off of the norm - which is the current ratio counter to map size. Does that make any sense?

Would SVG graphics help us with this desired functionality of being able to change that ratio - in particular being able to make the counters be smaller relative to the map?

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1956712638, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUXG3Y5TSXZVVSOBHILYUX4RPAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGY3TCMRWGM4A . You are receiving this because you were mentioned.Message ID: @.***>

uckelman commented 4 months ago

The default unit for SVG is pixels (but these are not screen pixels, they're abstract pixels). I would not recommend using any of the other absolute units, as you will inevitably come to grief by ending up with a mix of units.

GordonMolek commented 4 months ago

Thanks, I'll look into that.

On Wed, Feb 21, 2024 at 9:15 AM Joel Uckelman @.***> wrote:

The default unit for SVG is pixels (but these are not screen pixels, they're abstract pixels). I would not recommend using any of the other absolute units, as you will inevitably come to grief by ending up with a mix of units.

— Reply to this email directly, view it on GitHub https://github.com/vasl-developers/vasl/issues/627#issuecomment-1956901141, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYLTFUVWMMTKQQWQ6BCHTCDYUYFQTAVCNFSM4LRCVSM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGY4TAMJRGQYQ . You are receiving this because you were mentioned.Message ID: @.***>

vasl-developers / vasl

Using SVG for VASL Discussion #627