Making big PDF maps
- Thread starter Morte
- Start date
Good morning, All,
Some of my work using sec2pdf should be posted soon at Elvwood's Underdeveloped Sectors website, where I've been working on the Empty Quarter sector:
http://www.elvwood.org/Traveller/Sectors/EmptyQuarter.html
I sent him the first set of data I've developed, which is for the Classic Traveller Era, and includes the *.sec file and three PDFs generated using sec2pdf. As I'll be away from the computer this week with the US holidays, I don't know when he'll have them up, so I figured I'd post an early announcement here for those interested. Right now, it's the old page, but I hope it'll change over within the next day or so. A Galactic *.sar file will be ready by this weekend, as well.
The Gateway Era information won't be released to the website until my article on Collapsing CT Era UWPs to Gateway Era UWPs is released here on COTI, although you will see bits and pieces of it in the Spinward Ho! fanzine, once that's off the ground and running.
The TNE:1248 information won't be released until the TNE 1248: Bearers of the Flame sourcebook is released by QLI as well.
Both of the above will be supported by *.sec files, PDFs, and *.sar files as well. Figured the project would help me become better at developing world data, etc., as well as contribute to the OTU in some small way.
More Later,
Flynn
Some of my work using sec2pdf should be posted soon at Elvwood's Underdeveloped Sectors website, where I've been working on the Empty Quarter sector:
http://www.elvwood.org/Traveller/Sectors/EmptyQuarter.html
I sent him the first set of data I've developed, which is for the Classic Traveller Era, and includes the *.sec file and three PDFs generated using sec2pdf. As I'll be away from the computer this week with the US holidays, I don't know when he'll have them up, so I figured I'd post an early announcement here for those interested. Right now, it's the old page, but I hope it'll change over within the next day or so. A Galactic *.sar file will be ready by this weekend, as well.
The Gateway Era information won't be released to the website until my article on Collapsing CT Era UWPs to Gateway Era UWPs is released here on COTI, although you will see bits and pieces of it in the Spinward Ho! fanzine, once that's off the ground and running.
The TNE:1248 information won't be released until the TNE 1248: Bearers of the Flame sourcebook is released by QLI as well.
Both of the above will be supported by *.sec files, PDFs, and *.sar files as well. Figured the project would help me become better at developing world data, etc., as well as contribute to the OTU in some small way.
More Later,
Flynn
In the past, I've polled people about the .sec file formats, getting people's input and suggestions. In this thread I'd like to ask y'all's gut feelings about a variant .sec file format I've been thinking of.
This is not a brand-new format, but rather modifications of the current one. I have two different mods I'd like to put up for discussion, especially to folks who have written software to manipulate SEC data.
1. Sector tags. This variant is only used when data from multiple sectors is used; for instance, a 'four corners' map, or an 'edge' map (Raschev and Alenzar, for instance). This variant has several alternatives. The least damaging would include the two-character sector code in front of the hex number. For example, the world Shush in the Corridor sector:
Standard:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Shush 0221 C662262-7 Lo Ni 623 Na M V </pre>[/QUOTE]Variant 1:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Shush eE-0221 C662262-7 Lo Ni 623 Na M V </pre>[/QUOTE]An alternate for the above would be to use the ring/ray notation instead of the sector-hexnum notation:
Variant 2:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Shush 9949/62771 C662262-7 Lo Ni 623 Na M V </pre>[/QUOTE]The above notation is less intuitive, but general for a much larger chunk of the galaxy.
2. XBoat tags. Currently, I store Xboat link data at the end of the UWP line; this way, the data is all together in one place. For example, Calida is a hub with comm/trade links to two neighboring worlds, one of which is a 'red line' and one of which is a 'blue line':
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Calida 0603 A667722-B C Ag 420 Im F V M V :0602r, 0604b</pre>[/QUOTE]However, Flynn's border code is decoupled from the map data. Is that a better way to store XBoat data as well?
This is not a brand-new format, but rather modifications of the current one. I have two different mods I'd like to put up for discussion, especially to folks who have written software to manipulate SEC data.
1. Sector tags. This variant is only used when data from multiple sectors is used; for instance, a 'four corners' map, or an 'edge' map (Raschev and Alenzar, for instance). This variant has several alternatives. The least damaging would include the two-character sector code in front of the hex number. For example, the world Shush in the Corridor sector:
Standard:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Shush 0221 C662262-7 Lo Ni 623 Na M V </pre>[/QUOTE]Variant 1:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Shush eE-0221 C662262-7 Lo Ni 623 Na M V </pre>[/QUOTE]An alternate for the above would be to use the ring/ray notation instead of the sector-hexnum notation:
Variant 2:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Shush 9949/62771 C662262-7 Lo Ni 623 Na M V </pre>[/QUOTE]The above notation is less intuitive, but general for a much larger chunk of the galaxy.
2. XBoat tags. Currently, I store Xboat link data at the end of the UWP line; this way, the data is all together in one place. For example, Calida is a hub with comm/trade links to two neighboring worlds, one of which is a 'red line' and one of which is a 'blue line':
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Calida 0603 A667722-B C Ag 420 Im F V M V :0602r, 0604b</pre>[/QUOTE]However, Flynn's border code is decoupled from the map data. Is that a better way to store XBoat data as well?
You might want to look at the format I use for my pdf maps -- all sector names are a two character code indicating its location in the galaxy, followed by a dash, followed by the sector name. Then my software figures out what sector a world is in by looking at what file it found the data in.
Good afternoon, Mr. Greely,
I was curious if you had spent any more time on this project, either in rewriting it or in adding other features? Do you have any future plans for sec2pdf?
I really enjoy what you have done, and appreciate the beauty of the PDFs it creates.
Thank you for your time,
Flynn
I was curious if you had spent any more time on this project, either in rewriting it or in adding other features? Do you have any future plans for sec2pdf?
I really enjoy what you have done, and appreciate the beauty of the PDFs it creates.
Thank you for your time,
Flynn
Mr. Greely, and other interested parties,
I am wanting to create a document for my players that includes astrographic maps generated by sec2pdf, but I have no idea how to export them out of the PDF as image files so that I can import them into the document file. Does anyone have any idea how I might be able to do this?
Thanks in advance,
Flynn
I am wanting to create a document for my players that includes astrographic maps generated by sec2pdf, but I have no idea how to export them out of the PDF as image files so that I can import them into the document file. Does anyone have any idea how I might be able to do this?
Thanks in advance,
Flynn
In Acrobat Reader 6, there's a button next to the "select text" tool. The tooltips identify it as the "Snapshot Tool." It looks like a weird little camera with a dotted line around it. Select that, then click and drag a box over the part of the PDF you want to export. When you let go of the button, the section is copied to the clipboard. Then simply paste into your document.
I think other versions of Acrobat Reader will do this too, but the procedure might be a bit different.
I think other versions of Acrobat Reader will do this too, but the procedure might be a bit different.
Mr. Greely,
I was curious if you had done any more work on this particular project? In particular, I was wondering if I could request the addition of a legend on the right-hand side, as your list of future features suggests.
Thank you for all your hard work on this project,
Flynn
I was curious if you had done any more work on this particular project? In particular, I was wondering if I could request the addition of a legend on the right-hand side, as your list of future features suggests.
Thank you for all your hard work on this project,
Flynn
Mr. Greely (et al),
I've started breaking your script into bits -- namely, packages. In doing so I'm learning your script's logic flow and intents. I'd like your opinions and suggestions.
First, I'm building three helper packages:
Grid.pm - this package manages grid-related data, such as edge data, dimensional data, etc.
StyleMgr.pm - this packages is an API for accessing style-related data. I've reformatted style and configuration data into YAML documents (which have built-in parsing support into native data structures anyway).
PDFWriter.pm - this package is an API for the specific drawing routines for the program. All of the drawXYZ functions are in here. This package calls methods on the PDF object, Grid object, and StyleMgr object.
Orchestrating the effort is the script, Uwp2Pdf.pl, which reads in the main configuration file, uses the UWP and UWPTools packages to parse in UWP data, and calls methods on the other three packages to actually build the output file.
I'm still working on the whole thing, so I've yet to know if my efforts are successful.
I've started breaking your script into bits -- namely, packages. In doing so I'm learning your script's logic flow and intents. I'd like your opinions and suggestions.
First, I'm building three helper packages:
Grid.pm - this package manages grid-related data, such as edge data, dimensional data, etc.
StyleMgr.pm - this packages is an API for accessing style-related data. I've reformatted style and configuration data into YAML documents (which have built-in parsing support into native data structures anyway).
PDFWriter.pm - this package is an API for the specific drawing routines for the program. All of the drawXYZ functions are in here. This package calls methods on the PDF object, Grid object, and StyleMgr object.
Orchestrating the effort is the script, Uwp2Pdf.pl, which reads in the main configuration file, uses the UWP and UWPTools packages to parse in UWP data, and calls methods on the other three packages to actually build the output file.
I'm still working on the whole thing, so I've yet to know if my efforts are successful.
I can give you a hint, but not tell you exactly.
Look at the sub gridseup()
Line 306: sets the $grid(origY)
Line 356: sets the $grid(width)
These two values need to be adjusted so $grid(origY) and $paper($PaperSize)
- $grid(width) are the same value.
Perl is not one of my first languages, so I'm a little hazy on what changes to make, exactly.
You may also want to make a direct inquiry on his site
Look at the sub gridseup()
Line 306: sets the $grid(origY)
Line 356: sets the $grid(width)
These two values need to be adjusted so $grid(origY) and $paper($PaperSize)
- $grid(width) are the same value. Perl is not one of my first languages, so I'm a little hazy on what changes to make, exactly.
You may also want to make a direct inquiry on his site
