Note: For those of you coming in late, a few of us in the list are working on a solution inspired by messages 3667 and 3668. The idea is to create a system whereby a user can "print" a PDF where layers on your original map translate to layers in a PDF. This would allow the end-user of the map to turn layers on and off.
In my opinion, this is a cool project not just because we are building a nice new function for Maptitude users, but because it represents a new step for the list. Some of us (first Larry Manire and Armando Scalise led the way, then others such as Josh and myself followed suit) have posted code snippets or even whole applications for others to use for free. But this is the first time (that I am aware of) that we are building a community-wide project on the list. Do you program GISDK? Please look at the "known issues" and suggest solutions. Don't program GISDK? That's OK, we still need people to suggest features, weigh in about how the program should behave and test the product as it develops. --- Josh, Sorry you're under the weather. I also understand that you folks are getting a "little" snow. -1) I'm a bit conservative in the naming/numbering. I was thinking alpha in the sense of the fact that we haven't really decided what the final feature set should look like, and that anyone not interested in being part of the design/programming process (and you don't have to know GISDK to help us design this thing) would be advised to steer clear for now. 0) Good point. I hadn't considered that. Since the layer in question would go on top, a band-aid would actually be a terrible idea. 1) That's correct: any inset map (whether it is actually inset in the map or appears elsewhere on the layout) is treated like all other annotations... in a single layer. As currently designed, you can turn off the annotations layer if the inset map, the legend, or a freehand arrow is blocking something you want to see. But then *all* annotations, including the map title get turned off. There's no reason (other than the complexity of the programming) to prevent us from dividing these up into their own layers (one for inset maps, one for the legend, one for all other annotations), at which point the end user can switch any of these on or off at his/her leisure. I'd like to know what people likely to use this function would prefer to see happen here. 2 & 2.5) Nothing wrong with those code snippets that I am aware of. It does lead to a further proliferation of layers, and too many layers may be as annoying as too few. Since I wasn't sure if that functionality was tied to the searchability issue, I decided to leave it out for the moment. Again, though I have done most of the design/programming to date, I view this project as a listwide collaboration (and hope that it will lead to other such efforts in the future). So it would be helpful for folks in the list to weigh in. One point about PNG though: I have resisted using raster graphics (including Larry's clever workaround-- see message #3678) because they will turn to crap as you scale in/out. Is this something people care about? Again, this is a place where list input will be helpful. --- In [email protected], "Josh Rosenthal" <[EMAIL PROTECTED]> wrote: > > Moshe, > > Unfortunately, I'm ill, so still not back at a copy of Maptitude. As such, > preliminary comments only. > > -1) Thank you. Alpha it may be, (eh... Beta. Problem is, it's Beta for > half of the solution and the other half is still preAlpha) but its a solid > starting point, and automates the Maptitude side of a very nice > functionality. > > 0) Be very careful with Bandaids/white space labels unless you actually want > it to cover everything underneath. They wreak havoc with the PDF as we > usually require white space to be transparent, and not white (exception > might be under insets, see below). Deleting the white space in the PDF is > impossible (that was what led me to the nightmare of the Illustrator > solution, wherein one of the purposes of illustrator is to find all 300 or > so white space objects and delete them. Select similar will not work > reliably). Note that white space can be used for images if we are willing > to accept the extra step of opening in Paint.NET, magic wanding the white > and deleting it (ie: still better to avoid). Basically, only use white > space if you will not want something to ever be underneath them. If you > want your layer to be the top of the stack at any point, avoid bandaids. > > 1) Inset maps. If I read the code and spec right, you've opted to allow > inset maps, but not divide them into layers. Only the main (largest) map > will produce layers, everything else will be part of the annotations layer, > with the layout frame. I'm hesitant as to how this will work with > transparency vs. necessary white space underneath the insets. We might need > to produce the white spaces manually, but testing will tell. I also wonder > if we should stick the insets on a separate layer from the rest of the > Layout Annotations, as they explicitly will obscure data, while most of > those annotations do not. (ie: different potential draw locations in layer > structure). > > Not sure its a good idea, but for what its worth, one could also envision > handling insets by... > Measure location of all maps, pick one to start, hide/move all, keeping ID > and associated maps. Print layout objects, delete layout obj, move mapview1 > back into place, cycle that map, remove, get new map, repeat... Repeat. > Reassembly becomes complex to a significant degree as we very easily will > have dozens of maps. > If I can figure out an iText solution (any Java or C# programmers out there > interested in helping? iText also allows for allowing zoom to control view) > for reassembly, the complexity might at not require working manually in the > java console in Acrobat. Unfortunately, I haven't had any luck at all with > iText, so for the time being, we're stuck with the Java Console, so even if > we have the code to allow inset maps, as a practical limitation, it may be > too unwieldy to multiple views worth of layers. > > 2) > Searchable Text > Searchable text remains searchable in Layered PDF if it was searchable in > the unlayered PDF. If the layer is off, the user will be prompted asking if > they want it turned on. Unfortunately, it appears to search layers in order > in some odd order (possibly based on location on page?) rather than starting > with layers that are on. This presents a possible reason for having some > text layers actually be printed as PNGs so as to keep them unsearchable, but > hopefully can be worked around for the time being. > > 2.5) Text Label layers. I still think there'd be a value in separating the > labels off into their own layer for each map layer, ie: each maptitude layer > creates 2 PDF layers, feature and label. Was there a problem with the code > you'd proposed? > > *Re: labels, we can convert automatic labels to "freehand" with: > ConvertAutomaticToManualLabels(map_name) > HideMapLabels(map_name) > > Then we can select them all and delete them with: > annots = SelectAllAnnotations("map|"+map_name) > DropSelectedAnnotations(annots)* > > If its just me who finds this useful, I should be able to carve the extra > step into the code. The only drawback of it should be in the PDF assembly > where one now needs to add (and the user needs to navigate) extra layers, > but it should make complex maps much more readable. > > Otherwise, very cool. Still no luck on the Zoom controls, although the > function is part of the PDF spec (see section 4.10.1 from the v1.6 PDF > Reference), and is accessible with iText (there is a setZoom method). > Unfortunately, it doesn't appear to be accessible via the Java console > directly, so our easy little Javascript hack won't also give us zoom > control. Other faster ways of adding the layers rather than working with > the Java Console probably include "eDoc PDF Printer", a reasonably cheap > program which seems to allow merging PDFs as layers. > > Thanks a lot, > Josh > > > On Jan 14, 2008 12:21 PM, Moshe Haspel <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Josh's thoughts helped me conceive a new way of handling this. > > In v0.1 we started with a map, and in a series of loops, built a bunch > > of different layouts. > > > > For v0.2, I took a somewhat different tack: > > > > 1) Start with a complete layout. The user should have everything set > > just the way he/she likes it, just as if he/she was about to press the > > print button. > > > > 2) Capture some basic info about the layout (such as its name and size). > > > > 3) Search through the layout for maps. Find the map occupying the most > > area on the layout [I often put an inset map on my layouts, so we'll > > want to differentiate], and get info about it (such as location). > > > > 4) Move this map off of the layout and print to PDF. This will give us > > a PDF layer containing ALL annotations except for the map: titles, > > images, legends, and anything else found on the layout. > > > > 5) Drop everything on the layout. > > > > 6) Cycle through layers, and determine which are shown and which are > > hidden. > > > > 7) Turn off all layers in the map. Place the map (with all layers off) > > in the layout and print. This will cause all of the annotations on the > > map itself (e.g. north arrows, freehand items) to print in their own > > layer. > > > > 8) Drop all annotations from the map so that they'll show up only in > > the one layer. > > > > 9) Cycle through all layers in the map, turn them on in turn (only the > > ones that were initially shown, of course) and each to its own PDF. > > > > 10) Close everything down and print a happy message. > > > > There are still some issues that need to be dealt with (see "the known > > issues section" at top of the file). And there are sure to be > > additional things that I have not anticipated. > > > > Give it a whirl and post comments to the list. I'm about to get busy > > at work, so I won't have much time to work on this... but we now have > > enough of a skeleton that people can agree to work on smaller pieces. > > > > P.S. Text items (labels, legend text, titles) appear to be searchable > > in the PDFs. Don't know how that will play out when you create the > > layered document. > > > > > > --- In [email protected], "Josh Rosenthal" <maric423@> wrote: > > > > > > Moshe, > > > > > > > > 1) Agreed on dispensing with the picklist, although, in all honesty, a > > > robust version of the code should have it, as the goal for any such > > snippet > > > is to minimize the effort involved in going from a dataset to the final > > > product, and having to remove layers from a file has the potential > > to get > > > repetitive. That said, I'm all for it not being around for now. Mike, > > > Larry, you've both got immediate applications for this code. Any > > thoughts? > > > > > > 2) Interesting, but I suspect we'll need the printer preset for the > > layout > > > to work anyway (try seeing what happens when you make a layout with > > a paper > > > printer, draw a view, and change the printer to PDF Creator. I > > always get a > > > strange shift in map view location to be offcenter, even if the > > paper size > > > of my printer matches the size for the PDF printer). Thus, if we can > > > require that as part of our spec for the user when building a > > template, and > > > then directly use the printer from there, this would be ideal. > > > > > > 3) I'm actually not sure why we need to create separate layouts. > > Can we > > > not set the map view to our map, and refresh it programmatically, or is > > > there some other reason I'm missing? > > > > > > 4) I like the solution of the legend as a separate layer. In > > Acrobat you > > > can set the layer to always display, or make it part of the base layer, > > > etc. Should be nice. > > > > > > 4.5) Text & Searchable Text. Sadly, before I had to leave my > > > maptitude/acrobat setup on friday I didn't have time to explore this > > > completely. Here is what I have. > > > > > > One of the great joys of PDFs is that text is searchable, and as > > such, that > > > labels, if converted to text, are also searchable. Unfortunately, when > > > testing, I was unable to get automatic labels into the PDF (this may > > have > > > been my system which was in desperate need of a reboot towards the > > end of > > > the day), and only could get searchable labels by producing a series of > > > manual labels, turning off the layer, refreshing the layout (now > showing > > > only the labels), and printing to PDF. This AnnotationLayer PDF, once > > > brought into Acrobat, was searched when one uses the find function in > > > Acrobat. You will *not *see this behaviour in the current Proof of > > > Concept uploaded as that was based on PNGs, rather than directly being > > > output to PDFs. Note that if someone wants to have some annotations > > > searchable, and others not searchable (eg: don't search in the > > > boilerplates), the solution is to have some be images, and others text. > > > > > > Problems with Searchable Text. > > > a) Does it work for Automatic labels? If it does, it seriously raises > > > question if what follows is necessary. I still think it'd be nice, but > > > maybe not necessary. Certainly for zoom controlled annotations > > we'll need > > > them in separate layers. I suppose if it does work, the ideal would > > be to > > > have a variable that would say whether or not to separate > > annotations from > > > layers or not. > > > b) In any case, in theory, one wants searchable text to be in its own > > > separate layer. > > > Annotations are great, but they can easily hide data. Especially if > > > multiple layers have annotations.Thus... I guess... > > > > > > > > > - Turn on layer, > > > - show labels > > > - (if necessary?... should be able to spec that if you want a label > > > layer, create them as part of your base map and have them on, > > > thus, we check > > > to see if we should create labels by seeing if they're already > > there), > > > - convert to graphics, > > > - turn off layer, > > > - refresh layout, > > > - print, > > > - delete all graphics in map > > > - turn on layer, > > > - turn off labels (if necessary?), > > > - refresh layout, > > > - print, > > > - turn off layer, > > > > > > rinse repeat. Every layer (or every layer with labels) would thus get a > > > separate annotation PDF produced. > > > > > > c) Acrobat Search pans, not zooms. This is an ugly problem, even in > > a full > > > GIS. What should it zoom to? This can be dealt with by using > > bookmarks in > > > Acrobat rather than encouraging searching, but this is only a partial > > > solution. Not a maptitude problem, in any case. A better zooming > > solution > > > may be the key. The ideal of course, would be a way to use Acrobat > > (which > > > does know font size), to display at font size rather than zooming. Not > > > quite sure how that is accomplished though. > > > > > > 5) Legends... I'm not quite clear on how determining legend > > placement will > > > work. How can it be in a template, if the user cannot have it in a > > template > > > because there is no filled map? > > > > > > I do like the line of thinking with the layout naming scheme and the > > legend > > > logic (and layer order placement). Should make potential scripting > > easier > > > for the other side of things. Very nice. Also, I'm sure you're > > right about > > > PDF Creator, but as you pointed out, Acrobat can do this, and for > > the moment > > > we are assuming users will have acrobat handy (although, using iText > > would > > > allow this to function without a copy of Acrobat... which would mean > > > Maptitude layered PDF support using only maptitude and free products). > > > > > > In any case, very cool. > > > > > > Thanks a lot, > > > Josh > > > > > > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/Maptitude/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/Maptitude/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
