Web-based Automatic Sector Data / Map pdf Generator
- Thread starter Mickazoid
- Start date
Kem: For the time being, you can grab the source for Full-UPP and the SW4 software here:
http://www.columbia.edu/~mbk2109/traveller/SW4FullUPP-Source.zip
Thanks to you and ForTheKill for all of the support in getting this up and running. The help from my fellow Traveller players puts commercial software firms to shame.
I will be busy for a few days with a business trip; I will try to compile and run the binaries during my downtime and will post results here.
Just out of curiosity, do you think the web-based version will be up before or after next tanning season? (See, people really do read the old posts. ;-)
Kem
I will be busy for a few days with a business trip; I will try to compile and run the binaries during my downtime and will post results here.
Just out of curiosity, do you think the web-based version will be up before or after next tanning season? (See, people really do read the old posts. ;-)
Kem
Considerable progress since my last post.
Recompiled the binaries using the following command for each: gcc -arch x86_64 foo.c
All binaries compiled with a handful of soft warnings - which I ignored and forged ahead. Replaced the old binaries and fired up SectorMaker.sh per instructions. Results:
1. Generated a random sector with no issues. (Dancing around laptop commenced.)
2. Failed to generate a sector book from my own .sec file placed in the autogen folder. Long, long string of errors. (Facepalm.)
3. Noticed that your .sec files do not contain stellar data. Ran program using your .sec file copied to the autogen folder by itself and used the following command: sudo ./SectorMaker.sh Trojan_Reach dense mature 1 Trojan_Reach.sec 2
Generated full sector book (yay!) but the final switch (2) was ignored and the sector generated with the full encounter tables for each world.
Next step: Transmogrify my .sec file to match your format and run it again. Since I wanted the encounter tables anyway, no worries, but I thought this information might be important as you go ahead with the port to the web-based version.
Will post final outcome in a few days.
Kem
Recompiled the binaries using the following command for each: gcc -arch x86_64 foo.c
All binaries compiled with a handful of soft warnings - which I ignored and forged ahead. Replaced the old binaries and fired up SectorMaker.sh per instructions. Results:
1. Generated a random sector with no issues. (Dancing around laptop commenced.)
2. Failed to generate a sector book from my own .sec file placed in the autogen folder. Long, long string of errors. (Facepalm.)
3. Noticed that your .sec files do not contain stellar data. Ran program using your .sec file copied to the autogen folder by itself and used the following command: sudo ./SectorMaker.sh Trojan_Reach dense mature 1 Trojan_Reach.sec 2
Generated full sector book (yay!) but the final switch (2) was ignored and the sector generated with the full encounter tables for each world.
Next step: Transmogrify my .sec file to match your format and run it again. Since I wanted the encounter tables anyway, no worries, but I thought this information might be important as you go ahead with the port to the web-based version.
Will post final outcome in a few days.
Kem
I am having an interesting problem. It turns out that SectorMaker.sh is not reading existing .sec files from the autogen directory but reads only from the trav/sectorfiles directory. Not a big issue; when I run the program with the existing .sec file (and its allegiance and route files) it works perfectly. However, when I substitute my own .sec file in the trav/sectorfiles directory and run the program with an allegiance file I created from the existing one and a route file created by SectorMaker on an earlier try, I get a PDF with blank subsector maps and the subsector name concatenates incorrectly on the pages. The other output files generated all look OK to me.
There must be some difference between my files and yours but I cannot find it, and I think it is in the .sec file. I have matched formats as exactly as possible (did you know your .sec files have exactly 2 blank spaces or 1 blank space and a TAS code at the end of each world line?) to no avail. I cannot figure out why yours work perfectly and mine do not. (Yours do have their own cool .sec icon but I don't think that's it. BTW, you are going to have a real problem with uploaded .sec files to your web-based version; the most common versions - like the ones from the Traveller wiki and travellermap.com - are a different format than the .sec files you are using. You will need a good parser to process the various input files.)
Here are Dropbox links to copies of the files I used and the output file. Any thoughts? I did notice that I need to use sudo to run the SectorMaker script but I don't understand why that would interfere with the graphics operation of drawing the subsector maps for one .sec and not the other. Any ideas?
Kem
http://dl.dropbox.com/u/14464683/Trojan_Reach.pdf
http://dl.dropbox.com/u/14464683/Trojan_Reach_alliances.txt
http://dl.dropbox.com/u/14464683/Trojan_Reach_route.txt
http://dl.dropbox.com/u/14464683/Trojan_Reach.sec
There must be some difference between my files and yours but I cannot find it, and I think it is in the .sec file. I have matched formats as exactly as possible (did you know your .sec files have exactly 2 blank spaces or 1 blank space and a TAS code at the end of each world line?) to no avail. I cannot figure out why yours work perfectly and mine do not. (Yours do have their own cool .sec icon but I don't think that's it. BTW, you are going to have a real problem with uploaded .sec files to your web-based version; the most common versions - like the ones from the Traveller wiki and travellermap.com - are a different format than the .sec files you are using. You will need a good parser to process the various input files.)
Here are Dropbox links to copies of the files I used and the output file. Any thoughts? I did notice that I need to use sudo to run the SectorMaker script but I don't understand why that would interfere with the graphics operation of drawing the subsector maps for one .sec and not the other. Any ideas?
Kem
http://dl.dropbox.com/u/14464683/Trojan_Reach.pdf
http://dl.dropbox.com/u/14464683/Trojan_Reach_alliances.txt
http://dl.dropbox.com/u/14464683/Trojan_Reach_route.txt
http://dl.dropbox.com/u/14464683/Trojan_Reach.sec
Kem,
Your .sec file has ~ half a dozen lines that are one character (space) longer. XCode -> Show Invisibles under Editor menu should show extra spaces - or use another editor that will show whitespaces (and EOL as well, though your file had LF only, so probably ok).
No idea if this is the issue for you (I've never run this), but given your description, if one of the modules expects fixed length or sees another field due to extra whitespace (more likely) this may be throwing off the subsector mapping...
(Wow - that courier looks like crap compared to the rest - no offense to anyone ... )
Your .sec file has ~ half a dozen lines that are one character (space) longer. XCode -> Show Invisibles under Editor menu should show extra spaces - or use another editor that will show whitespaces (and EOL as well, though your file had LF only, so probably ok).
No idea if this is the issue for you (I've never run this), but given your description, if one of the modules expects fixed length or sees another field due to extra whitespace (more likely) this may be throwing off the subsector mapping...
(Wow - that courier looks like crap compared to the rest - no offense to anyone ... )
You say you have original source data (.sec +) files that work?
Then some things you could try:
Then some things you could try:
Make sure that actually still works (with files in place)...
Then try deleting all but the first 2 and last 2 lines in the working .sec file -> does it still work?
(If not - then your editor may be corrupting codeset or unseen characters like EOF not supported...)
If it worked - then copy one of your lines into the working 4 line .sec file - after the first two lines (delete any duplicate system) and before the last two -> does that work?
(If yes - then you likely have some unseen character in the wrong place in other lines; invalid/unhandled data; and, or have exceeded a limit like total lines...)
(If no - try another line, in case you got a bad one... and then post here so we can see it...)
Then try deleting all but the first 2 and last 2 lines in the working .sec file -> does it still work?
(If not - then your editor may be corrupting codeset or unseen characters like EOF not supported...)
If it worked - then copy one of your lines into the working 4 line .sec file - after the first two lines (delete any duplicate system) and before the last two -> does that work?
(If yes - then you likely have some unseen character in the wrong place in other lines; invalid/unhandled data; and, or have exceeded a limit like total lines...)
(If no - try another line, in case you got a bad one... and then post here so we can see it...)
drkem -
In order to regenerate existing .sec files, they need to be in the original 'trav/sectorfiles' folder - when in doubt, conform to the original Mac version's syntax rather than forthekill's mods (made to the Ubuntu version).
Here's what I see in your sec files:
1. (As BytePro mentioned above) lines 30, 32, 36, 55, 73 and 152 have one too many characters at the end of each line. Try 'show invisibles' in TextWrangler or your text editor to check the line length.
2. My version of the Trojan Reach .sec file starts with '#Version: 3' at the top of the .sec file. Try placing that at the top of the sec file so every step of the the parser understands the format (not sure if this is deprecated in all versions of the SW software).
3. Your alliances file has a blank line at the end.
In addition,
4. you have #Trojan Reach: Mongoose at the top of your files. Some step in the chain may be barfing over a line of comment text (rather than the version identifier I mention above).
Good luck!
LOL - warning, if you build a script that generates printer-quality sectorfile LBB pdf's, your reward will be is it looking so good that the gripe is over fonts
In this case, as 'crappy' as some might think it is, 'Courier' is one of only a handful of monospace fonts suitable to the task. Using a monospace font on a table of data like the sector data and animal encounters pages ensures that the UPP characters and the gaps between them all line up without fail. If there were a better-looking monospaced font amenable to tables of data, or an easier way to manage that many columns' 'tab' stops in plain text files (compounded by the variable nature of UPP's and their length), a better looking font could be used.
There isn't.
In fact, I also kind of like the 'old old school' vibe of tables of data in typewriter-esque Courier. Maybe that's a retroactive justification after wrestling with this problem for ages.
In order to regenerate existing .sec files, they need to be in the original 'trav/sectorfiles' folder - when in doubt, conform to the original Mac version's syntax rather than forthekill's mods (made to the Ubuntu version).
Here's what I see in your sec files:
1. (As BytePro mentioned above) lines 30, 32, 36, 55, 73 and 152 have one too many characters at the end of each line. Try 'show invisibles' in TextWrangler or your text editor to check the line length.
2. My version of the Trojan Reach .sec file starts with '#Version: 3' at the top of the .sec file. Try placing that at the top of the sec file so every step of the the parser understands the format (not sure if this is deprecated in all versions of the SW software).
3. Your alliances file has a blank line at the end.
In addition,
4. you have #Trojan Reach: Mongoose at the top of your files. Some step in the chain may be barfing over a line of comment text (rather than the version identifier I mention above).
Good luck!
LOL - warning, if you build a script that generates printer-quality sectorfile LBB pdf's, your reward will be is it looking so good that the gripe is over fonts
In this case, as 'crappy' as some might think it is, 'Courier' is one of only a handful of monospace fonts suitable to the task. Using a monospace font on a table of data like the sector data and animal encounters pages ensures that the UPP characters and the gaps between them all line up without fail. If there were a better-looking monospaced font amenable to tables of data, or an easier way to manage that many columns' 'tab' stops in plain text files (compounded by the variable nature of UPP's and their length), a better looking font could be used.
There isn't.
In fact, I also kind of like the 'old old school' vibe of tables of data in typewriter-esque Courier. Maybe that's a retroactive justification after wrestling with this problem for ages.
Last edited:
As a developer I can tell you there are a lot of better looking monospace fonts.
The original encounter tables from 30+ years ago are not monospaced - while not easier, it is quite doable.
BTW: - the values in the Wounds column in drkem's encounter tables do not look correct (blanks and negative numbers).
As a developer I can tell you there are a lot of better looking monospace fonts.
The original encounter tables from 30+ years ago are not monospaced - while not easier, it is quite doable.
BTW: - the values in the Wounds column in drkem's encounter tables do not look correct (blanks and negative numbers).
Agreed. But not in the "standard set."
http://www.lowing.org/fonts/images/showPreview.php gives a nice overview.
My favorites: Andale Mono, Century Schoolbook Monospace, Courier New
Thanks to all for suggestions. Will try out in a couple of days - I'm away at a business meeting. :-(
Curse work for interfering with my hobbies!
Another advantage of monospace fonts is that Excel can import data directly from a text file without standard delimiters (like a .sec file); it has a nifty tool to define imported fields by columns in the text file.
Kem
Curse work for interfering with my hobbies!
Another advantage of monospace fonts is that Excel can import data directly from a text file without standard delimiters (like a .sec file); it has a nifty tool to define imported fields by columns in the text file.
Kem
That just means picking one of the bind-in allowed fonts in OTF format, and binding it in.
Understood - that's what I did with 'Optima' and 'Univers' - in my case, I actually created the TTFs from decrypted postscript fonts.
But alas, since the original LBB look had data tables that used Univers with manual tab stops, using ANY monospace font would be a divergence from 'canon' anyway.
So rather than introduce another (unprecedented) font into the 'Univers/Optima' design scheme, I did the typographically minimalist thing and chose to stick with Courier (thus having a font design family w/one 'serif' (Optima), one 'sans serif' (Univers) and one monospace font (Courier). (Note: Optima is in fact a sans serif but the variable stroke widths suggest to me that it functions in the LBB scheme visually as the 'serif' font).
As an ersatz member of an LBB design 'theme' Courier is both contemporaneous to the time of Classic Traveller (it's an 'old school' font compatible with the 70's-80's LBB look) and as a monospace font it solved the problem well enough for me to make the tactical design decision to focus on other things.
But alas, since the original LBB look had data tables that used Univers with manual tab stops, using ANY monospace font would be a divergence from 'canon' anyway.
So rather than introduce another (unprecedented) font into the 'Univers/Optima' design scheme, I did the typographically minimalist thing and chose to stick with Courier (thus having a font design family w/one 'serif' (Optima), one 'sans serif' (Univers) and one monospace font (Courier). (Note: Optima is in fact a sans serif but the variable stroke widths suggest to me that it functions in the LBB scheme visually as the 'serif' font).
As an ersatz member of an LBB design 'theme' Courier is both contemporaneous to the time of Classic Traveller (it's an 'old school' font compatible with the 70's-80's LBB look) and as a monospace font it solved the problem well enough for me to make the tactical design decision to focus on other things.
Last edited:
Quite.
Those purdy maps really deserve a full 'canon' treatment. Whipped up some PostScript to do the trick:
This layout is 'canon' from Supp #2, with adjustments for the longer weapons names that were not originally allowed for. The TERRAIN: text could be changed, and the world name added, and things would be a near match to that 'canon', other than the use of Wound modifiers rather than pre-rolled values.
Haven't used/looked at the generation programs yet (just found them) - so I'm sure I missed some special cases. (Ex: shortened 'claws +1, teeth +1' to fit - suspect 'battle+4' has an extra space that would make it too long.) Used your (old?) SpinwardMarches PDF from columbia.edu as a sample.
The PostScript can easily be 'wrapped' around the fixed format source text via a script.
The same approach could be used for the sub-sector listings - I could lay these out in columns, but I personally have no 'canon' sources to match (my CT collection consists of the CT Reprints of Books 1-8, and LBB Supp #2 & #12). If anyone has a page scan (high-res being best), I should be able to match it.
Question - Where is the most recent code? (So I can check it against what the PostScript is handling before sharing the code so anyone who wants to can play with it...)
The last round of edits suggested by Mickazoid did the trick. My output looks great; all I need to do is adjust borders and routes, add colors, etc. (Just in time, too; my players arrive in Trojan Reach on Saturday.)
I'll keep an eye on this thread for further updates on the software. Thanks again for all the help!
Kem
I'll keep an eye on this thread for further updates on the software. Thanks again for all the help!
Kem
Byte: Looks great! Did you do that postscript coding of that text manually (in plaintext, in Illustrator, etc.), or is the process you employed compatible with automation using the 'enscript' program that the sector scripts use (on both Mac and Ubuntu)?
Please detail what you did specifically to achieve this - including posting a code sample of the postscript if you would be so kind - so those of us familiar w/the script as it exists can evaluate how to incorporate it without incurring a redesign.
Most of all, do you think it will be possible to use your method to apply italic just to specific lines of text, and conform blocks of text selectively to the 'tabular' layout, with the EXISTING script? Text search-and-replace after the fact might be a good approach if it is possible to do programmatically. Would we need to 'wrap' each page in that enclosing postscript?
If this kind of layout can be automatically applied to the txt files converted to postscript using 'enscript', it could be a great addition to this software!
The code is in the same place it's been for years - the latest mac version can be found here:
http://www.columbia.edu/~mbk2109/traveller/SectorMakerScripts.zip
And forthekill's ubuntu version can be found here:
http://frontiers.forthekill.com/sectorMaker/SectorMakerUbuntu.zip
Last edited:
That's great to hear Kem!!!! Enjoy!
Glad to hear you got it working drkem99!
Basically: prep.ps + for each line of text adding ( in front and appending ) doLine at end + done.ps => output.ps.
Likely replace enscript as it allows formatting text using just script commands to build up a printer/PDF-ready PostScript file. Probably akin to what enscript is doing for ya, only this is customized to this project and intended to be 'editable' by anyone (though any code can be intimidating... and I'm a bit, er, 'over-experienced' at times).
PostScript could support just appending the text files and extra info to a .ps file or even access files directly when it is interpreted (I've used both these approaches before - PostScript is a general purpose language). But, for multiple platform use, its less risky - due to permissions, path conventions, EOL/EOF and encoding issues, etc. - to just kludge together the file with scripts.
I've a busy day, but will try to add more later (after investigating the contents of sectormaker.zip ).
Just checking since that looked old (2006?) - had pulled from http://micki001.cnc.net/trav/SectorMakerScripts.zip yesterday.
Just plain hand edited text.
Basically: prep.ps + for each line of text adding ( in front and appending ) doLine at end + done.ps => output.ps.
Likely replace enscript as it allows formatting text using just script commands to build up a printer/PDF-ready PostScript file. Probably akin to what enscript is doing for ya, only this is customized to this project and intended to be 'editable' by anyone (though any code can be intimidating... and I'm a bit, er, 'over-experienced' at times).
(No experience with enscript, though. No reason to since first hand coded PostScript, uh, 24 years ago - initially with no books/instruction, just raw print files and guessed operators - all while limited to two $%^# blinking LEDs on an Apple Laserwriter II NTX for feedback (as it was 'custom' wired, to a non-serial port on an IBM, so no bi-directional feedback) ... those were the days! )
Paging, initial and continuing page numbering and headers could be handled with/within the PostScript file in a number of easy ways. It handles selectively typesetting (tab layout, italics, bold) based on content and should be fairly easy for others to change. That facilitates 'dropping' it into a script setup - with easily handled minor exceptions... Any parenthesis and backslashes require a backslash pre-pended. So, simple search and replace parsing for those exceptions would be in order for each line prior to appending to 'output.ps'. The PostScript code handles the rest - ex: replacing the header with a 'cannon' version; and, shortening long weapon codes.PostScript could support just appending the text files and extra info to a .ps file or even access files directly when it is interpreted (I've used both these approaches before - PostScript is a general purpose language). But, for multiple platform use, its less risky - due to permissions, path conventions, EOL/EOF and encoding issues, etc. - to just kludge together the file with scripts.
I've a busy day, but will try to add more later (after investigating the contents of sectormaker.zip
).Thanks!
Just checking since that looked old (2006?) - had pulled from http://micki001.cnc.net/trav/SectorMakerScripts.zip yesterday.