OK,

I tried adding a ID to the layers and sorting them, then dfeed them trough one single port to the PdfPageFormatter.

This helps simulating a layerorder.

Not ideal, because you might need to keep the order per layer unchanged, requiring more transformers. (counter per layer, count total per layer, create ID per layer and then create a order ID beased on these).

I still prefer separate inputports. So how do i align those?(equal properties do not garantuee alignmnent)

Hi Gio,

Just to be certain, you mean you can't get 2 page objects to align on the page in PDF even though they are aligned just fine in the PDFPageFormatter? (because if that's the case the title of your question is somewhat misleading, as I don't see where the layer order would come into play).

As a general suggestion I would recommend removing your PDF writer and creating it again if this is a 2-year old workspace as there's been a lot of development on the PDF front lately (and layer order is definitely supported)

layer order is controlleed by a formatattribute or simply ordering objects by sorting.

If 2 or more layers are fed to the PdfPageFormatter and are aligned according to the property values and i write it out using pdf writer, they are not aligned in the pdf when i use Adobe to view it.

If i use only 1 inputport then of course they are aligned. But then the only way to control the drawing order is to sort the objects by layer. Adding a order attribute that is. Latter i find less desirable.

The end issue is layer order control using the PdfPageFormatter.

Okay, what (I think) happens is that the PDFPageFormatter will try and fit your data into the boxes, which can be a bit awkward if the height/width ratio of the data is not the same as that of the box, which in turn can make the alignment go off. Best suggestion I can give you on that respect is to add an empty box (no fill, no stroke) around your data and to control the size of that box to be the same height/width ratio as the box in the PDFPageFormatter.

Layer order itself is controlled with a format parameter on the output feature type, as far as I've been able to test that works even after the data is run through a PDFPageFormatter.

I try to say it again.

2 or more layers. Same content. 2 or more inputports to PDFPF.

Size and location properties are exactly the same.

Order control trough inputportcontrol.

result: Misalignment.

Same layers to 1 inputport of PDFPF, they align. Then order control only possible trough sorting objects.

I have read the pdf readers and writer section, have built my own custom pdf writer years ago. And i know there is a requirement for aspect ratio of worldframe and content.

To me it seems the PDF pageformatter does not execute this correctly.

So it is rather useless.

I know what you mean. Give me a while because I'm sure I have a solution or suggestion.

Right. I think I remember now. Yes, you are correct. You enter two datasets into different ports and use the same size box inside the PDFPageFormatter - but they don't align properly.

That's because the data is scaled to fit those boxes, and your two datasets are not exactly the same size.

What I do to workaround this is create a bounding box for the larger dataset, and copy it into the smaller dataset. That way both datasets become the same size and there is not problem in the PDFPageFormatter.

Does that make sense? Basically you need to ensure both sets of data have the exact same extents - and I find a bounding box is the easiest way to achieve this.

Appearantly the pdf formatter uses a boundingbox extent to set its worldframes. Where it should, in my opinion respect scaling or at least offer a option for it.

Adding a record with the largest BB is not very handy. To align labels (points...) i would have not copy the largest BB, but i would have to add 2 records, the lower left and upp right vertex location of the larger BB.

So what the PDFPF misses is a option to respect common worldframe extent (or have a switch for local frames..) and common scaling. (something like "Use extent of:" Pageobject1, Pageobject2 etc..)

Or automaticaly detect overlapping extents upon wich it would merge their BB.

Also a alginement menu would be nice.

I

Yes, please add that to the ideas page, then we can see what other users think. I agree, we should have some sort of common scaling option

The team met today to discuss this situation. We agree that the design causes misunderstanding and potentially awkward workflows. It invites you to use multiple input ports, but then causes you scaling troubles if you do.

For now we agree the best option is to route all the geospatial data going to a particular frame into 1 port. That will ensure it gets the proper scaling. Then you can split that data out afterwards using a TestFilter or FeatureTypeFilter depending on your setup, for final routing to the correct layers in the PDF.

Our plan is to revisit the design for FME 2017 so that the Input ports define "layers" and you can assign layers (and orders) to viewports within the transformer UI. And we'll probably create an output port for each input port so that you can do additional routing thereafter. Rough sketch of a viewport attached below:

Thanks for raising this, we can and will do better.