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" <[EMAIL PROTECTED]> 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
> >
> >
>
>
