Making big PDF maps

[Flynn]

Greely,

You're creating an awesome tool to help Traveller mappers everywhere.

Thanks a lot!

Now, when did you think you might complete that script that helps calculate borders for the metafile?

-Flynn

 

[jgreely]

Originally posted by Flynn:
Now, when did you think you might complete that script that helps calculate borders for the metafile?

Oh, soon after I start it. I've sketched it out on paper (see above, way, way above for the basic idea), but haven't had time to code it up and test it. Real Work intruded for much of the weekend.

-j

 

[Flynn]

Mr Greely,

With the coming weekend, do you feel you might have time to create the border generation script you described a few pages back? I'm curious to see how it works. I'm even considering tackling the problem myself, but have two other personal programming projects to finish up first, one of which I should complete this weekend, if not both.

Good luck to you,
Flynn

 

[jgreely]

Maybe Sunday. I nailed down some more of the details this afternoon, but got distracted cleaning up sec2pdf and adding a commented map style file example that creates white-on-black maps (for the truly traditional "let's waste an ink cartridge" look

).

-j

 

[Anthony]

Hm. Wow, Traveller map generation. Been a while since I bothered to update my code (not sure if the nroute.c on the web is current anyway). BTW, I congratulate anyone who manages to parse how nroute.c works; I released it for public use because I didn't see any reason to make it secret, but I can't say I designed it to be comprehensible to anyone other than myself.

Not sure I understand the nature of the problem you have with how I draw borders, though.

Btw, I like sec2pdf, though it looks like it would have an unreadably small font size if you put a full sector on 8.5x11.

 

[jgreely]

Originally posted by Anthony:
Not sure I understand the nature of the problem you have with how I draw borders, though.

Simply put, I think there are too darn many of them, adding to the visual clutter (see subsector P of Delphi or Ley, or subsector O of Trojan Reach). The fact that they're a mass of disconnected line segments rather than closed paths is also a bit distracting on-screen, but not a big deal in print.

My goal is borders that resemble those a human would draw, and this human would not draw 12 completely separate Cs borders in subsector P of Delphi.

Btw, I like sec2pdf, though it looks like it would have an unreadably small font size if you put a full sector on 8.5x11.

Yes, it would be, although this is completely customizable with style files. Lots of people want PDFs for online viewing, however, where the base paper size doesn't really matter (witness the domain map, which is officially 8.5x11 even though it's absurd to think of reading it at that size), and there are also a number of poster-printing drivers that let you tile a PDF across as many sheets as you want.

And, of course, the text on an 8.5x11 sector might be unreadable, but it makes a terrific cover page for a collection of quadrant/subsector maps, to help you keep track of what's on other pages.

Personally, I think 11x17 makes for a quite readable sector (especially since my last round of adjustments), and a perfect quadrant. It would be a very silly subsector, though, so I didn't bother pre-generating them at that size.

-j

 

[jgreely]

Okay, I've got a working version of my border-generation script ("allygen") posted here. Feedback welcome. It seems to produce reasonable results for the allegiance codes in all the sectors I've tried, as well as generating nice pocket empires when you tell it to ignore pre-existing allegiance codes.

Documentation is sparse at the moment, but I've supplied an example below the download link.

-j

 

[Flynn]

Mr Greely,

I have tried out the allygen script, and in general I really like the results. I did find one complication that I'd like to ask you about. I've noticed that the borders calculated do not extend off the map, and assume that the polity is self-contained within the sector itself. However, for an Imperial frontier sector, such as the Spinward Marches, that leaves us with some editing to do to pull the borders off the edges. Is this something that could be addressed programmaticly, or is it something I'll have to modify by hand?

Also, in the Pocket Empire generation option, I noticed that there's no empty space left over for Non-Aligned worlds. Would you mind reviewing your thought processes on how these borders are generated with us here, as I'm curious as to how your script selected these borders?

Thanks for this, btw. It's a very great tool!

Enjoy,
Flynn

 

[clementk]

<waves> Like the pdfs on the site! Downloaded the scripts but not had a chance to examine yet.

A request though, on the by subsector pdfs is it possible to also put the Subsector Letter (A-P) or if not a page number? As an option if nothing else. It'd make it a lot easier to remember which subsector is where instead of by subsector name.

Casey

 

[syrja]

Hi,

In GDW's Domain of Deneb map, vertical subsector borders are drawn exactly between hexes and horizontal borders so that they show more clearly where systems belong.

I experimented with sec2pdf by adding few constant offset values (+4, -6) to subsector borders:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">sub drawdividers {
my ($count) = @_;
setstyles("map-dividers");
for my $i (1..($count-1)) {
my $x = 1.5 * $i * ($grid{cols}/$count) * $grid{edge} + 4;
$pdf->move($grid{origX} + $x,$grid{origY});
$pdf->line($grid{origX} + $x,$grid{origY} + $grid{height});
$pdf->stroke;
}
#horizontal
for my $i (1..($count-1)) {
my $y = (2 * $i * $grid{rows}/$count + 1) * $grid{cos} - 6;
$pdf->move($grid{origX},$grid{origY} + $y);
$pdf->line($grid{origX} + $grid{width},$grid{origY} + $y);
$pdf->stroke;
}
}</pre>[/QUOTE]I'm not perl or pdf expert. So, there is probably more elegant solution than raw offset values, but it seems to work well with sector maps.

Is it possible to print system names and UWPs using opaque background? That would make them more readable in map cluttered with different kind of borders and trade routes.

Mikko

 

[jgreely]

Originally posted by Flynn:
I've noticed that the borders calculated do not extend off the map, and assume that the polity is self-contained within the sector itself.

That's an upcoming option, similar to -s and -n, allowing you to specify alliances that are allowed to extend outside the sector. Maybe -e for "empire". There are two ways to do it: post-process @R (the list of hexes in a border), or simply extend the loops by one on each end, and ignore allegiances not specified in -e. Not sure which way I'll go with it right now.

Why did I leave it out? Mostly because I needed to restrict the output to something that I could see in sec2pdf while I was debugging.

Also, in the Pocket Empire generation option, I noticed that there's no empty space left over for Non-Aligned worlds.

Yup. You have to run allygen twice right now: once with -i to generate the pocket empires, which you examine for regions that you'd like to make non-aligned, and then a second time using the generated SEC file and the -n option, to actually exclude them.

I didn't want the program to decide for you which areas of your map should be non-aligned. Creating a SEC file containing the new allegiance codes gives you more options.

Would you mind reviewing your thought processes on how these borders are generated with us here, as I'm curious as to how your script selected these borders?

The basic idea was simple: the quality of a world's starport represents its influence over nearby hexes. Ties are broken in favor of the world with the highest TL, and if those are tied, the highest population. I simply sort the list of worlds and loop across them in order.

I arbitrarily decided that a class A starport will claim every currently-unclaimed hex within Jump-3, class B within Jump-2, and class C within Jump-1 (side note: the -f option adjusts this range; "-f 1" increases A to 4 and D to 1, "-f -1" decreases A to 2 and C to 0". E and X never influence any hex but their own).

Every world (occupied hex) will claim its own hex, unless someone else already has. By default, all worlds are pre-claimed; the "-i" option ignores that data and allows them to be claimed by nearby worlds with better starports. Essentially, a pocket empire is built when a class A starport claims a bunch of nearby class B and C starports (and possibly lower-tech/pop class A's), which then extend their parent's influence.

After every world has had its say, I make a pass across the empty hexes, and each one that is adjacent to one or more worlds joins the largest neighboring allegiance (based on number of hexes). This has the effect of filling in gaps along the edges.

Worlds defined as non-aligned then get a chance to clean out adjacent empty hexes, but not if it would obviously split an allegiance and create a bunch of orphan worlds.

Finally, there are a number of cleanup passes that get rid of some absurd claims on empty hexes. Hard to describe, easy to see if you tinker with the code and use the -D option.

Todo: the "empire" option, and a fix for the "enclosed non-aligned worlds" problem (most visible in Alpha Crucis; the data is actually computed correctly, but I'm not detecting completely-surrounded non-aligned regions that need a border to show that they're not members. Again, -D demonstrates the problem).

-j

 

[jgreely]

Originally posted by Casey:
A request though, on the by subsector pdfs is it possible to also put the Subsector Letter (A-P) or if not a page number?

Actually, it defaults to the subsector letter if you don't name them in the metadata file. On the to-do list is a map legend that would show graphically where it's located in a sector, like the published maps.

-j

 

[jgreely]

Originally posted by syrja:
In GDW's Domain of Deneb map, vertical subsector borders are drawn exactly between hexes and horizontal borders so that they show more clearly where systems belong.

Haven't seen that one. I fussed over subsector boundaries quite a bit, and decided that the only correct method was to actually snake them along the hex edges, which was useless if I planned to cover them up with regional borders. If I were going to change it, I think I'd snake them along the hex edges as a dashed line that was above everything else, so that edges and borders would show through enough to remain clear.

Is it possible to print system names and UWPs using opaque background? That would make them more readable in map cluttered with different kind of borders and trade routes.

I've been struggling with the best way to solve this one. The short answer is that printing an opaque bounding-box around each string produces results that just look too darn ugly to me. Worse, the boxes must be sized to fit around every possible character in the font, no matter how far it extends above or below the baseline. This increases the chance that other text fields will be clipped.

Sadly, there's no simple way to generate an "outlined" font where each character is stroked with a contrasting color, but I'm considering faking it with PDF's synthetic fonts (create a phony "bold" version of the font and print it in the background color, then print the normal version on top). It would inflate the size of the PDF file somewhat, but restricting its use to just name and uwp fields would keep it from getting too silly, and of course I'd make it optional.

-j

 

[Flynn]

Mr Greely,

I see that you've posted some updates to your website, in regards as to what the updated script can accomplish. Notably, I see that your script can now label bordered regions, and will soon have multi-sector domain map support. Wow! I'm looking forward to actually seeing how that works out once you've released that code.

Again, thank you for your hard work, and I shall sing your praises whenever I can.

With Regards,
Flynn

 

[jgreely]

The multi-sector support code is currently hard-coded to assume a four-sector domain, and it really needs some cleanup before I post it. Basically, I extended the -d option to allow multiple SEC files (which generates multi-page PDFs at whatever level of detail you select), and then added an additional option to hack the size calculations and position all four on the same page. It works, but it's neither robust nor pretty.

Before I post the new version, I want to clean it up and extend it to support some other variations, such as two sectors side-by-side on a landscape page. Right now some of the calculations are being done in the wrong order, which makes things messy.

-j

 

[Flynn]

Wow, that sounds great, J! Thanks for all the hard work... Do you think you could also allow for two sectors above and below one another as well, just to allow both orientations?

Man, you are making that script dance,
Flynn

 

[Falkayn]

Originally posted by J Greely:
The multi-sector support code is currently hard-coded to assume a four-sector domain, and it really needs some cleanup before I post it. Basically, I extended the -d option to allow multiple SEC files (which generates multi-page PDFs at whatever level of detail you select), and then added an additional option to hack the size calculations and position all four on the same page. It works, but it's neither robust nor pretty.

FYI, there is a slight problem with your domain map (or perhaps your .sec files). The Gaspar Belt (1530) is shown with an allegiance of VI, but the border around it includes it within the Trindel Confederacy.

Another minor point is that the Mische Conglomerate border colour is very close to that of the Free and Holy Federation of Amil, which is right next door to it.

[just doing my bit for interstellar peace ]

 

[jgreely]

Mental hiccup. The solid black line under it in GtD led me to leave it out of the Viyard borders, and then I went ahead and included it in Trindel. Oops.

As for the Amil border, that was a quick fix after I realized I'd used orange for both Amil and Viyard, which didn't come up until I joined them in the domain map. I really need to figure out a good color palette and redo them all.

I'm uploading corrected versions now.

-j

 

[Falkayn]

Thanks!

 

[Falkayn]

Had a go at using sec2pdf with some pretty colours (which I'm still working on). Here is a screen-capture of the overall domain view:


VERY cool, thanks J!