~dr|z3d
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@zzz
%Liorar
+Afkaid
+Hikari
+Unbur
+Xeha
+acetone
+profetikla
+semantica
+snex
+uop23ip
+weko
Arch
DeltaOreo
FreefallHeavens_
Irc2PGuest30202
Irc2PGuest42421
Irc2PGuest83825
Leopold
Nausicaa
Onn4l7h
StormyCloudInc
Titlacahuan_
anon4
anontor2
anu
cumlord
itsjustme
limak
not_bob_afk
poriori_
rs231
thetia
u5657
dr|z3d
svg artifacts gone.
dr|z3d
no editing required, just: paint-order:stroke; (assuming you're applying a stroke to the countries).
zzz
have you gotten <use href=... to work to load a sub-svg in? I'm stumped...
dr|z3d
yeah, easy enough.
dr|z3d
make sure it goes at the bottom of the svg, undearneath the other layers.
dr|z3d
iirc, <img href="/full/path/to/foo.svg"> should work.
dr|z3d
*<image
zzz
it has to be use, not image, to be in the DOM
zzz
did you try image or use? working on what browser?
dr|z3d
one sec, I'll try and recreate.
dr|z3d
<image href="/themes/geomap/lines.svg" height="100%" width="100%">
dr|z3d
firefox (librewolf)
zzz
ok
dr|z3d
assuming the image is the same dimensions as the layers underneath, you don't need width and height.
zzz
but according to mozilla:
zzz
SVG files displayed with <image> are treated as an image: external resources aren't loaded, :visited styles aren't applied, and they cannot be interactive. To include dynamic SVG elements, try <use> with an external URL. To include SVG files and run scripts inside them, try <object> inside of <foreignObject>.
dr|z3d
yup, you're getting a static image overlay with image.
dr|z3d
if you want interaction, that's a different proposal.
zzz
in the html, are you loading your basemap svg with <img src= or <object data= ?
dr|z3d
neither. using <svg> inserted into the page with a file loader.
zzz
hmm
zzz
thats the third option...
dr|z3d
yeah, do that and then you just inject the extra layer into the page / svg.
dr|z3d
let's see if I can get something working with <use>
zzz
about to try <object>
dr|z3d
<use> looks like it's internal to the svg itself, so doesn't appear to solve anything.
dr|z3d
though maybe the mozdev page I'm reading isn't the full picture.
zzz
not true, although most examples are href=#foo, href=xxx#foo is also supported
dr|z3d
that was the page I was on. :)
dr|z3d
When you see "#shadow-root (closed)" in the Elements panel of your browser's developer tools, it means that you are trying to access or inspect a shadow DOM tree that is closed or encapsulated. Shadow DOM is a feature of the Web Components technology that allows web developers to create encapsulated components with their own DOM trees, styles, and behavior.
dr|z3d
A closed shadow root is created when the mode option is set to "closed" when creating the shadow root. A closed shadow root is not accessible from outside the component, meaning you cannot traverse the DOM tree or manipulate its contents directly. This helps maintain the encapsulation of the component's internal structure and styles, preventing them from being affected by external CSS rules or JavaScript.
dr|z3d
In the context of using <use> to load an SVG into another SVG, the issue might arise if the source SVG is inside a shadow DOM tree with a closed shadow root. Since the shadow root is closed, the browser cannot access the SVG elements inside it, and therefore, the <use> tag cannot reference those elements.
dr|z3d
from where I'm sitting right now, appending the lines layer to the existing svg looks like the easiest method.
dr|z3d
ie. load map svg from file, append extra layer(s), write to page.
dr|z3d
I've kept all the resources outside of jars for now to make for easy adjustments.
dr|z3d
jars/wars
zzz
firefox got the janks and consistently wasn't even displaying the whole base svg, had to restart it
zzz
now have to go back and retry things that weren't working
zzz
fuuu it gagged again
zzz
did you have a problem where it quit drawing countries after Burundi?
dr|z3d
no, not seen that.
dr|z3d
did you remove the landmass group?
dr|z3d
or, better still, use the svg up on git.skank as your starting point.
zzz
yeah I did
dr|z3d
ok
dr|z3d
how are you loading the svg?
zzz
atm with <object but was happening before with <image
zzz
it almost always happens if I load the image in its own tab
zzz
but now it's happening on the console page too
dr|z3d
can't get to happen here, either with the svg inline on a console page, or loading the svg separately.
dr|z3d
I'm also delaying the display of the countries for half a second so they all render at once, looks better than them rendering individually.
dr|z3d
not long enough to be a noticeable delay, but long enough so that the entire map comes into view.
dr|z3d
map loads, gray, then the heatmap loads.
dr|z3d
slight transparency on the sea background so it blends better with the console theme.
zzz
you sorted the paths by country name, right? before they were only semi-sorted
dr|z3d
yeah
dr|z3d
put the ids at the front of the paths.
zzz
I'm not using the sorted flavor, and I don't think you should either, because some of the paths start with 'm' instead of 'M'
zzz
so that's relative to the end of the path before it, afaik
zzz
but maybe the first m/M doesn't matter and it is absolute?
dr|z3d
I think you might be right re relative vs absolute, might be some slight adjustments to the ordering required.
zzz
this page isn't super clear about it developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths
dr|z3d
with that said, I'm not noticing any visual discrepancies, maybe I haven't look hard enough.
dr|z3d
yeah, doing an eyeball check vs the cartosvg meractor map at cartosvg.com/mercator I can't see any issues with the new ordering.
dr|z3d
if there was an issue, Albania and Algeria would have disappeared. still present and correct :)
dr|z3d
That seems pretty clear: All of the commands also come in two variants. An uppercase letter specifies absolute coordinates on the page, and a lowercase letter specifies relative coordinates (e.g., move 10px up and 7px to the left from the last point).
zzz
yeah but does 'last point' include from a previous element?
dr|z3d
good question. I'd expect to see some breakage on my reordered map if that was the case, but strangely there is none.
dr|z3d
let's try something...
zzz
I tried changing the m to an M for Ethiopia and it borked it, so whatever
dr|z3d
yeah, borkage.
dr|z3d
I just swapped out all d="m for d="M, same.
zzz
so sorting didn't break it
dr|z3d
not afaict
zzz
which surprises me, but I know nothing
dr|z3d
maybe the sort kept the order of the elements starting with m.
dr|z3d
as you say, it was mostly sorted before.
dr|z3d
there are a few countries that the map omits.. falklands, tibet (?), not seeing banladesh either, and western sahara also untagged.
dr|z3d
will require some svg surgery to activate those, they appear to be conjoined as a single path.
zzz
there's always going to be some mismatch, we have three sources of data: google, cartosvg, geoip
zzz
code needs to handle it
dr|z3d
*nods*
zzz
if anything you may as well remove all the single-point countries
zzz
although some of them may become real paths if you go back to cartosvg and rerender at 1600, which you need to do at some point
dr|z3d
there is no rerender for svg, there's just a viewbox.
zzz
no I mean you have to start over on cartosvg.com
dr|z3d
this was the source of the map -> cartosvg.com/mercator
dr|z3d
I can probably scale the image in inkscape to be 1600px wide, not sure how well it'll handle the ids.
zzz
no you have to go to cartosvg.com/app and make a custom one
dr|z3d
yes, but no.
zzz
ok mr. 'upscaling is bad'
dr|z3d
yeah, it's bad for bitmaps, it doesn't matter for svgs.
zzz
sure it does
dr|z3d
no, listen to me. it doesn't matter for svgs :)
zzz
that's how you get single-point countries
zzz
at a big enough resolution, all countries would have a real path
zzz
now, whether 1600, which is 2.2222 times bigger than 720, would be a decrease in one-point countries, dunno
dr|z3d
ok, I see what you're saying, but it still doesn't matter because we're scaling the svg in the viewport, and countries will remain barely visible regardless.
dr|z3d
and regarding scaling in inkscape, you'd be scaling the current heavily optimized svg, so not much doing.
zzz
the "look" of the svg looks fine when upscaling, but you don't regain the detail you lost when downscaling to 720
dr|z3d
not important enough to redo, countries that are that small aren't worth worrying about imo.
zzz
so maybe upscaling from 720 is fine, but know it's a concious choice and you're losing detail you could have if you started from scratch at 1600
dr|z3d
you'll also note that the max width for output on the carto app is 800px.
dr|z3d
not so much a choice as "here's a map that roughly conforms to zzz's bitmap, let's run with this". :)
dr|z3d
so the issue with the map isn't upscaling or downscaling per se, it's the heavily optimized paths.
dr|z3d
no matter, I don't think it's worth worrying about tiny countries anyway, most of the islands I'm looking at in the map that are super small are larger than 1 pix and do have shape.
snex
whats the smallest country that even shows in netdb?
snex
singapore?
zzz
hmm, 800 max, too bad
zzz
720 it is then
zzz
i have to restart this stupid computer, I think something is borking firefox
dr|z3d
the other issue with wanting more definition is that you end up allowing sub-pixel values and then the size and rendering times of your svg explodes.
dr|z3d
blame snap, zzz.
dr|z3d
I generally get rid of snap and install firefox and/or librewolf from the repos. saves a lot of hassle.
dr|z3d
tuvalu, snex
dr|z3d
or the orkney isles. aka dunno.
dr|z3d
also, if no one else noticed, they've got a new interim ceo at mozilla.
dr|z3d
her last job was working on portable breast pumps, so she's obviously absolutely perfect for the job.
cumlord
someone has to keep homelander in check
dr|z3d
the other thing we're forgetting about the map in use, zzz, is the embedded country ids and associated tooltips. that was specific to the demo mercator map, don't think that's available on from the app.
dr|z3d
ok, we've got the country ids, so I'm wrong about that.
dr|z3d
what we've also got which could conceivably be ported across is less optimized paths.
dr|z3d
eg: <path d="M184.89,25.349L187.272,24.463L186.714,21.074L188.104,20.102L187.41,17.228L188.658,17.908L190.907,17.658L190.504,16.262L191.895,14.708L195.168,17.346L201.112,17.273L202.335,16.652L202.171,14.407L206.476,13.765L207.341,12.416L209.046,13.62L211.467,12.167L213.56,9.676L216.081,9.838L219.224,9.224L220.931,11.394L223.635,11.116L224.142,10.78L226.662,13.808L228.152,13.769L228.534,15.277L227.686,16.364L224.26
dr|z3d
8,17.442L222.685,19.289L221.186,23.369L220.381,24.198L217.394,30.869L211.121,32.544L206.961,32.197L205.968,33.441L202.069,34.718L199.021,36.197L195.846,36.004L193.053,34.491L191.427,32.38L187.694,29.394Z" id="Hungary" class="country"></path>
dr|z3d
note the decimal places absent from our current map.
dr|z3d
yeah, not outside the realms of possibility to port over the smaller countries if that's required.
dr|z3d
not convinced it's worth the effort right now, maybe with inline zoom and pan (which I've had a brief look at) it would make more sense.
dr|z3d
from the app, the svg map is around 7-8 times the size of the optimized map.
zzz
my firefox issue is some sort of heisenbug, it happens about half the time with inspector closed and all the time with inspector open. chrome is fine.
zzz
I got <use href= working