provide an XML2PDF print service proxy

[vvmruder]

This pull request contains changes to XML which are necessary to satisfy XML2PDF print service. This is only a first approach. If we will see too heavy changes we will implement a dedicated XML2PDF renderer to produce such XML as second step.

[vvmruder]

with the fix #628 and this changes I was able to generate a PDF
0fc65a05-153e-4de7-806c-7742af465d84.pdf
There is still some problems to solve:

• GML is not valid in the opinion of XML2PDF service (therefore real estate highlight is not shown)
• The xlink thing is not necessary in my point of view
• XML2PDF handles our approach of 'mixable' languages in an extract not properly (that's why some content is lacking).

I'am in contact with GISDATEN AG to find a solution on that.

[pramisters]

• According to GIS Daten AG (20.03.2019) they will solve the xlink issue with the next release of XML2PDF.

• As XML2PDF expects decoded URLs pyramid_oereb should not encode URLs when a XML dataextract is requested URLs are encoded in XML-Dataextracts #820

[jwkaltz]

@vvmruder we have tested your code with @pramisters in the Canton Zug installation, and it was working fine - without needing to change the XML templates. We only needed to add your proxy code. Perhaps the xml2pdf service has been adapted in the meantime.

There is an additional issue about missing geometry data, but I am working on a separate PR for that. In my opinion, if we rework your PR such that it only adds the code (without changing the XML templates), we can merge it into master.

[vvmruder]

@jwkaltz This sounds good. I planned to work on that today. So I will rework it and push again. Than it can be merged.

[vvmruder]

@jwkaltz It was coming into my mind that we had an issue with encoded URL's in XML. Is this solved too?

[vvmruder]

@jwkaltz About the codacy-bot issues: I don't know how to solve this, because the import statements are there for inter python version compatibility. Its correct that one of the import statements will not be used... Can you contribute on that?

[jwkaltz]

@jwkaltz It was coming into my mind that we had an issue with encoded URL's in XML. Is this solved too?

It seems so, yes. Since we used your code without changes, but did not change the XML templates, I am assuming XML2PDF changed something and the encoding is no longer a problem.

[jwkaltz]

@jwkaltz About the codacy-bot issues: I don't know how to solve this, because the import statements are there for inter python version compatibility. Its correct that one of the import statements will not be used... Can you contribute on that?

It looks to me like urlparse is not used in this file, so these 4 lines can simply be deleted? Or am I missing something?

[vvmruder]

@jwkaltz About the codacy-bot issues: I don't know how to solve this, because the import statements are there for inter python version compatibility. Its correct that one of the import statements will not be used... Can you contribute on that?

It looks to me like urlparse is not used in this file, so these 4 lines can simply be deleted? Or am I missing something?

Ok so will look at it again and remove. Maybe I was mixing something up.

[vvmruder]

@jwkaltz It was coming into my mind that we had an issue with encoded URL's in XML. Is this solved too?

It seems so, yes. Since we used your code without changes, but did not change the XML templates, I am assuming XML2PDF changed something and the encoding is no longer a problem.

So I will remove changes on XML. And commit again.

[vvmruder]

Since this is a actual bug I think we should resolve it soon. The URL's are encoded twice. This leads to problems with the XML handling. But I added a Bug #884

[vvmruder]

Just for clarification #884 will be solved in another PR. Not in this one.