Hi,

Is there a way of positioning stuff on a page without using absolute positioning?

If I wanted to place a table at the top left of the page (with certain border sizes etc... but wanted to keep it in the flow of the page with the other tables etc...

At the moment I've got a div set up with a border and it is positioned absolutely but this means the other parts of the page flow over/under it so I have to div them up and position them absolutely also.

Any help would be welcome.

I'd almost never use absolute positioning, I'd tend to use relative positioning for the whole page.

That's what I'd like to do.

The thing is this is for a printed document not a web page.

The document is converted from HTML into a PDF file on A4.

The page will never be resized and the actual HTML that is created (from the XML) will never actually be viewed. In fact it will probably be overwritten.

The document has...

[Header]
Company Logo in top left
Customer details below logo on left with a border
Document details on right in line with the customer details
[/Header]
[Body]
Item details spanned across entire page and flowing from page to page (i.e. if the table is too big it creates a new page with the same header) (qtys, amounts, prices, etc...)
[/Body]
[Footer]
Blank or total price etc...
[/Footer]

I'm really not sure what the best solution is for this?

In that case you can use absolutes to define your outer edges and then have all the tables inside position relative to what's around them, think that's going to be the easiest options.

The whole project sounds a touch 'messy' though, rather you than me for sure.

Well it all works at the moment.

The only thing is we are looking to produce these documents using XML.

By using XML we can export the data in one go as the language we use speaks XML. It then allows us to communicate with other companies that we use for out-sourced printing etc... Also for invoicing etc...

I'm trying to see how feasible it would be to convert our current documents to use XML and some styling file rather than the current HTML.

Basically it's a lot of work to get to about the same place we are now but in the end we'll have a hell of a lot more to gain from the documents.

The main reason for not using absolute in web pages is because of varying screen size, resolution etc etc. What you are talking about is an output for a known size etc so what is the problem about absoluting all the widths

I didn't actually think of that. I think the problem with absolute at the money is that we are trying to programmatically produce the HTML.

With XML we can just output the code and point it at a stylesheet.

Thanks

You shouldn't mix absolute and relative, and you should always use relative, unless there is a good reason not to.

Seeing as your data is in XML form, would something else be better for laying out the PDF? Immediate thoughts would be a LaTeX template. Not sure what you'd need to do on the web server end though.

Probably.

At the moment we have some software (that we have had for years) that converts HTML (and CSS) into a PDF.

The data we have goes straight from the db and is programmatically put into an HTML file.

I am looking at the poss of using XML as its easier for us to create and more universal.

If there are better ways of going from XML to a formatted PDF doc then please let me know. I'll have a look at latex (not sure what it is though)

Thanks

LaTeX is a super-duper-whizzy-fantastic typesetting markup language, that is normally compiled into a PDF.

If you just output <xml>, couldn't you just do an xslt transform on it to give you the html+css you require for your existing method? Why change it? It seems a bit meh, but it seems to work and xml doesn't look like that much of an improvement.

XML transforms to pdf are easy enough, used them on a legacy project for years so a company can make snazzy invoices

The problem we have is that the only format of output we have at the moment is HTML no XML at all.

The data is taken out of the DB and slotted programmatically into an HTML document. Each type of document Invoice, Despatch document, Order, Collection has its own program that creates the HTML file for that document.

Basically, everything is a bit all over the place.

By using XML we get an easy translation from DB data to the output file as the language we use has a (sort of in built) export functionality that will create an XML file in one line of code.

By creating the XSL files (which is what I'm experimenting with now) for each doc type (or even one for all) we can still produce our own formatted documents but it means the formatting is kept completely separate from the program code.

i.e. what we have now is [data and formatting program] = [formatted document]

If we want to change the format of the document we have to mess around with the program that also goes and gets the data.

If we use...

[data bit] + [formatting bit] = [formatted document]

We could also prob use a single data output program for all docs and then just apply different XSL files to them. Then we can alter the data or format easily and also use the data bit as a delivery tool to third party companies.

Basically it allows us to easily transfer data to other companies and makes it easier to maintain what we have.

I was playing around a bit today and finally got a bit more about what was going on.

I've never really been into web development or HTML or anything so it's a bit of a learning project for myself at the same time.

That XSL stuff is quite a powerful tool. I like it

Final update.

I've now got it all working together!

I've got the data being output into an XML file which is very good as it's a one liner to do it...



Then I convert the xml into html...



Then convert to PDF using our inbuilt functions that pass off to PrinceXML.

Then email the PDF file.

Basically with 4 lines of code I can go from the data xml to a sent email with the attached PDF.

LOVE IT!