• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.

Web-based Automatic Sector Data / Map pdf Generator

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.
Thanks for the background info - I figured you had handcoded it. It looks great - however, since this needs to be a COMPLETELY automated process, and in the interests of minimizing major changes (eiiminating enscript just for this purpose seems a major and perhaps premature step) we might look at embedding sets of codes in the text to be swapped for PostScript code using sed or the equivalent, to delimit the tabular text from the text to be postscripted?

Or perhaps hand-coded tab stops in the text (at the top of each column), or the equivalent...?

As a long-term PostScript user myself, I admire your hard-earned PostScript kung-fu (I was a PageMaker/Quark/Illustrator operator in the late 80's - 90's) and am very familiar w/its idiosyncrasies and its capabilities - but I am wary at the prospect of replacing enscript and having to re-solve all the problems enscript solved or avoids) solely to achieve this single design goal (tab-delimited tables of Univers rather than monospace Courier).

As an aside, it's true that monospace fonts work better in some other ways (eg one can check for the length in characters of a monospace line of text more easily than a proportional font), but this is a minor consideration.

Overall, to me rewriting so much of the code for this single reason (Courier tables) was beyond the threshold of the 'cost-benefit' - but it would be the kind of thing I'd love to see someone other than me struggle with successfully. If it could be achieved it would be a nice 'upgrade' to the existing script.
 
Last edited:
Hey M'Zoid,

A little bird told me that your scripts parse UWP lines too strictly for Don's data. I am sure I don't have the facts correct, but something must be up, eh? What seems to be the trouble?
 
robj - you gonna haveta be more specific.

:)

Seriously tho - by and large the parsing of UWP's is done by pre-existing packages (primarily the 'SW' and 'full-upp' packages, which I barely edited).

So, if you have any specific examples, it would be most helpful for trackin' down the gremlins.
 
BytePro - the script has a few steps where it converts from plaintext (.txt) to postscript (.ps) and then to .pdf format.

It may well be that a lot of the work you are suggesting can be done in that conversion step to PostScript without too many serious functional issues coming up - take a look at the lines of SectorMaker utilizing enscript and pstopdf.

Thanks again for the enthusiasm - it would e great to have your expertise in PostScript brought to bear!
 
No worries!

Except time - its past 4 in the AM for me and I just got around to checking out the SectorMaker stuffs...

The cgi looks pretty straightforward -> with descriptive naming and nicely commented. (Took me longer to edit this post than to read it and check out the dependencies!)

Yep, not only can we eliminate the enscript pretty painlessly, but greatly simplify the page header/background/cover stuffs. Result will be shorter, cleaner script with quite a bit of processing overhead removed - while adding readily customizable functionality.

Don't worry, I'll be doing all the heavy lifting. ;)

Anyway, it would be best to show, rather than tell.

BTW: Likewise spent many (sleepless) hours with those DTP apps starting with PageMaker in the late 80's. Most (virtually all) of the idiosyncrasies where due to them generating bad PostScript or using bad fonts - not because PostScript is lacking (pretty pathetic too - given Adobe's own involvement and the excellent documentation).

P.S. - regards the Don .sec issue posts above:
Joshua Bell said... (travellermap blog)

It looks like sec2pdf just has hardcoded field widths, which are too narrow for the data. You can modify this line in sec2pdf:

/^(.{14})(.{2})(.{2}) (.{9}) (.) (.{15}) (.) (.{3}) (.{2}) (.*)$/;

It should work if you change it like so:

/^(.*?)\s+(\d\d)(\d\d)\s+(.......-.)\s+(\w?)\s+(.{15,})\s+(\w?)\s+(\d\d\d)\s+(\w\w)\s+(.*)$/;
 
Sorry about the multiple points of confusion there. Let me clarify:

  • Don and I have been working on adding updated data to travellermap.com; we're not even bothering with SEC but tab-delimited files since it's easier to move in and out of spreadsheets and databases.
  • On demand, travellermap.com will generate SEC files. To accomodate some long names, these don't adhere to fixed width conventions. At the very least, they don't cap names to 14 characters.
  • sec2pdf is a tool by J. Greely from dotclue.org/t20 which parses SEC files and generates PDFs. Mickazoid is not the author; it's one of the suite of tools that she uses in the LBB generator this thread is about.
  • sec2pdf has hardcoded field widths, so it isn't happy with the SEC files travellermap.com generates. I'd asked Robert if he could bring his Perl and UWP skills to bear to make an updated copy of sec2pdf available.
  • After looking at the script myself, I made the aforementioned blog comment showing a quick-and-dirty improvement to the script to handle variable width UWPs. That's a subset of a robust solution, like pulling in Robert's UWP parsing library.
 
Ah, so sorry about that.

I do tend to prefer to add noise into a system, even when clarity is preferred. Comes from my love of cellular automata and neural networks. I'm becoming an old buzzard of a programmer, and cheerfully so. Let's hope it continues to mean gainfully employedfully so, as well.
 
Thanks for the info and the background - that tweak results in an empty sector map (a resultant step probably doesnt know what to do with the fields), so we are going to need to troubleshoot a bit before we can bring it into the SectorMaker script.

I'll volunteer one area of the script that needs massive updating - the score counting for determining the capital world. Due to my limited shell scripting knowledge I'm counting lines of text and shuffling them around, where a bit of adroit coding could probably improve performance significantly.
 
The files generated by travellermap also have additional information in the trade codes section (an O:XXXX code that I think is the world owner for worlds with a 6 (captive/colony) government code.) This displaces the data following the trade codes and programs like sec2pdf will have issues with that. Any .sec files generated directly from the Mongoose Traveller supplements will have additional trade codes (Ga, Ht, Lt) that result in some worlds having 6 trade codes; sec2pdf does not like that, either.

Just some comments from the peanut gallery. I'll let the pros go back to work. ;-)

Kem
 
Thanks for the info and the background - that tweak results in an empty sector map (a resultant step probably doesnt know what to do with the fields), so we are going to need to troubleshoot a bit before we can bring it into the SectorMaker script.

Yeah, regular expressions do work better when they've been tested. :p

If Rob has time for some Perl twiddling on sec2pdf that'd be ideal, since he's got a robust UWP parsing library. But it sounds like it would involve more than just fiddling with the UWP parsing if sec2pdf is confused by additional remarks data after the parse stage - thanks for the heads-up, drkem99.
 
Regarding my earlier suggestion about incorporating nroute.c into some of this work for trade map generation, I have been able to compile and run the program successfully on Mac OS 10.7.3 (see my post in the software section) so the code is still quite functional and will run on x86_64 systems.

It would really be neat to be able to generate trade maps and data for a sector in travellermap.com or along with mickazoid's SectorMaker script.

You know, something for you experts to do in all your free time... (crawls back into peanut gallery.)

Kem
 
Sorry, had this mostly done last week, but got creatively sidetracked and forgot to finish it… also forgot how much I enjoy PostScript! :)

tpsmash.gif


Many thanks for sharing your inspirational work Micki! This thread has motivated me to create a Classic LBB style project. (I'll share that in another thread.)

So, here is what I came up with... http://islandscluster.files.wordpress.com/2012/03/prep-ps.doc (rename to prep.ps), which is a PostScript file that supports non-monospaced tables and generating 'background' PDF pages. http://islandscluster.files.wordpress.com/2012/03/example-ps.doc is an example using data from SpinwardMarches_desc.txt and SpinwardMarches.sec (with name/hex swapped) from the SectorMakerScripts.zip. (pstopdf/Mac Preview should load after renaming to example.ps)

In its simplest case, append each line of text to prep.ps, formatted as a proper PostScript string [precede any backslash, open/close parenthesis with a backslash] and enclosed in parenthesis followed by ' doLine'. Before each section, things like sectionHeader, pageNumber, centerRule, etc., should be defined and setupPage called and each section should end with lastPage (see example.ps).

Get fancier, via simply appending Postscript code, as per example.ps. [I'll try to document those...] Other options, like page size, margins, fonts and even/odd header justify can be easily overwritten or changed in the prep.ps file. Changing live area and page sizes support differing bleed/trim area as well as accommodating making use of different sizes (without scaling - i.e. full us letter expands the space for each column in tables and the number of lines per page...).

Note, this is content based - i.e. it looks for matches like 4 digit valid sector hex numbers - alone indicating the start of a world listing; or, when on a line exactly 60 characters long, a subsector table row, etc. - deviating from the sample content may require changes. Special handling is also embedded for determining the start of a subsector listing (to add table header) and page overflowing (adds another page, with maphex number). Lines beginning with certain numbers or table structuring phrases could confuse it (look at /doLine procedure).

I started this just looking at the thread images and referencing LBBs - so, headers and other formating come straight from my books as I didn't use, or even look at for creation, any existing code. However, prep.ps is setup to make the entire PDF ready as the 'background' to merge with covers, TOC, info, maps, etc. After looking at the scripts, which you've very well documented and should work with this approach, I added subsector borders and the adjoining labels, so you can eliminate the 'background' PDFs and readily change headers. Sorry, I eye-balled the borders… easily adjusted. ;)

Noticed issues with current TOC, so threw in a TOC style handler (doTOCLine) so it can be fully created within the scripts. Pictured above is pure canon style - but yours (better, IMO!) is easily reproduced (see last page of example.pdf). ;)

Sorry the code is rather a jumble - my initial intent was just to demo the simple tab justify thing. Making a drop-in style solution added all the special case content handling. Tried to allow for text to normally fit (like changing 'Battle +4' to 'battle+4') - but make no guarantees when using different fonts and really wide letter combinations (Allegiance codes of WW?). I'd spend the time to throw in fancier and embeddable typesetting, and adjust the output of the other programs - but, I can more satisfyingly make my own than do that. ;)

I haven't actually run anything from the zip file here. My one Mac must remain pristine, and I'm not inclined to spend the time making it all work on any of my Windows boxes. However, aside from that, I am willing to help make it work (readily identified .cgi changes, but don't expect you'd have any problem with such). Mostly it should be a matter of dropping a number of calls to enscript in favor of appending formatted lines to a copy of prep.ps file.
 
This is undoubtedly going to take me some time to grok - but this looks really promising!

Just so I'm clear - the text (descriptions, animals, UPPs etc) on those samples was manually entered from the SectorMaker script's 'SpinwardMarches' .sec and text files, and we're not looking at the script's actual output?

Great job!!!
 
Glad it looks promising enough to look at!

Just so I'm clear - the text (descriptions, animals, UPPs etc) on those samples was manually entered from the SectorMaker script's 'SpinwardMarches' .sec and text files, and we're not looking at the script's actual output?

Correct - have no setup good for running the scripts.

The text was copied and pasted from the .sec and text file with (...) doLine added (and name/hex swapped in .sec). Each section starts with setupPage and lastPage, but the rest is totally optional. (Though no headers or page numbers will render without extra lines.)

Each section can have a header (start of section only), starting page numbers (and page increment), subsector number (for the little locator box), option to center or use the canon header rule, option to allow the subsector borders to scale with live area. Empty strings, zero and negative page numbers, zero subsector number and such allow disabling features. Originally intended to automatically determine subsector number (by hex ranges) and pull name from text for title and the locator box. Ditto for the World Descriptions section and even the TOC. But having manual control using simple cat ... >> (echo ... >>) from command lines is a lot more flexible, I think.

For script writing purposes, you don't need to do everything at once - aside from header/page number differences (which can be turned off with /pageNum 0 def and /sectionHeader () def, though I forgot to provide an option for empty space if you want to use your header 'background' PDFs), you can just do a section at a time...

For instance, append the World Description lines to prep.ps with:
setupPage
followed by (..) doLine for each line, and then:
lastPage
at end.

Get the 'fancy' header and page numbers appending the following before setupPage line:
/pageNum 38 def
/pageInc 1 def
/centerRules false def
/subsectorNumber 0 def
/sectionHeader (World Descriptions) def
So, here's the 'canon' style TOC from the example.ps:
% Canon TOC version...
/pageNum -1 def
/centerRules false def
/subsectorNumber 0 def
/sectionHeader (Table of Contents) def
setupPage
(ABOUT THE REMOTE SURVEY) (2) doTOCLine
( Introduction) (2) doTOCLine
...
(WORLD DESCRIPTIONS) (38) doTOCLine
lastPage​
To make it look like your TOC version (seen at end of example.ps) change true to false for /centerRules, set /pageNum to (1), and leave the page number (can be anything, like iii or 3-5) string blank () for the bold lines. Add empty lines between entries with a simple () doLine. (NOTE:Leading space is what determines if entry text is bold; and, the /subsectorNumber 0 def is the default, so is just there as a best practice - it controls render of the subsector locator box.)

For a 'background' (for pdftk) for the intro pages:
% background placeholder to consistently format header/footer
/pageNum 2 def
/pageInc 1 def
/sectionHeader (About the Remote Survey) def
/centerRules false def
setupPage
newPage
lastPage
This is a new section (i.e. has ruled header at top of page) with an extra 'empty' page, containing page number, achieved using newpage .

Do note, for script writing purposes, that text does not have to be on separate lines, as PostScript sees spaces, tabs, CR, LF and the like as a single whitespace.

P.S. - forgot to document that the .ps files use 3 character tab spacing.
 
Sorry for the Thread Necromancy, but...

Sorry to be engaging in Thread Necromancy here, but I have to ask. Is there a current public site where I can use this program to quickly get a sector made for a Classic Traveller game? The one I saw early in the thread no longer works, as the site apparently cannot be found.
 
https://travellermap.com/make/poster

This isn't the program above, but will make PDF of a sector's worth of data which looks professional.

I have found that, but I am also looking for something other than the Zhodani Base to create an entire sector with. (It's not a bad site, but because my browser can't use the Java it runs on (security reasons), I can only get an ASCII output which does not transfer over well at all to any document formats I have, and I don't exactly have so much time to burn making worlds the old fashioned way from the Disco Days when CT first came out).
 
Back
Top