![]() A more portable solution is to embed the SVG fonts into the maps. But of course, this won't work on any computer that doesn't have the proper fonts installed. The easy solution (at least for my development machine) is to install the fonts Dragons Abound uses into the system font directory, although this isn't as trivial as it sounds, because the font names much match and there isn't any easy way to change the name of a font in Windows. When the same file is opened in Dragons Abound, it looks for fonts in the system font directory, and there doesn't seem to be any way to specify another font directory. In the browser, these are applied to text by using a CSS “font-family" style, and before the map is generated, all the possible fonts are loaded into the Web page to be ready to use. Dragons Abound uses both web fonts and locally stored fonts, all in WOFF2 format. The easy workaround here is to save SVGs into a folder that has the resources in the correct places this could be the same root folder used by the webserver or a different location that has copies of the resources in the same (relative) locations. When I take that same SVG and open it in Inkscape, those relative paths are now treated as “file:" URLs and Inkscape looks for the resources relative to the folder where the SVG was saved. These are referenced in the original SVG by a relative path, e.g., “images/background0.png." My sources are then organized so that the little standalone webserver I use can find those resources in the specified places. The third problem has to do with images and other loaded resources. The workaround for that problem is to group all the elements in each Dragons Abound mask into a single (unnecessary) “group" element. Dragons Abound creates a number of masks with multiple elements. Apparently Inkscape itself only creates masks with a single element, and doesn't handle masks with multiple elements very well. The second problem is that Inkscape has some bugs in how it handles masks. This can be fixed by specifying “fill: none" where needed so that paths display the same in the browser and Inkscape. So when I open a saved SVG in Inkscape it is mostly black because the top-most layer in the map doesn't have a fill color. Specifically, if a path doesn't have a fill color specified, the browsers assume that it has no fill Inkscape assumes that it is filled with black. The first problem is that Inkscape makes a few different assumptions from Chrome & Firefox about how to display SVG. There are a couple of challenges in getting these maps working in Inkscape. In the past I've been able to cut & paste the SVG for a map into Inkscape, but the SVG for the world maps is so big that trying to cut & paste it crashes the browser! Fortunately, I found FileSaver.js and I can use that to save the SVG directly to a file, and then open it in Inkscape and create a very big image that way. I suppose I could scroll the map, capture multiple screens and stitch them all together, but that's a pain.Ī better solution would be to save the underlying SVG and then open it in a program like Inkscape. ![]() I've got a function to save the map as a PNG file, but it can also only save the portion of the map that is being displayed. With that fixed, the names are now consistent across the two maps:įirefox can generate a map this big, but I can only screen capture a picture at the maximum browser window size. ![]() (Which I still keep off-screen to avoid showing edge-effect problems.) Instead, I need to stop generating coastlines when I get near the real edge of the map. Now that the map can extend far beyond the edge of the viewport, that's not a good solution. To avoid that from happening I've just generated the visible coastlines. There's actually a “coastline" along the entire edge of the world, which - since it encloses the entire world - breaks some of the program logic if I actually create that coastline. ![]() In this case, the exception is that Dragons Abound is only generating the coastlines that are visible. But it only takes one exception to throw off the naming of everything that follows. Since different things are visible in the two views, and the naming process is driven by random numbers, different names result.Īfter looking through the code, I discovered that almost everything is being named whether it is visible or not. That's because Dragons Abound doesn't bother to name anything that isn't visible. You can see the geography is the same, but many of the names have changed.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |