The ALIGN attribute of table cells appears to be ignored. Prince left-aligns the text in all 3 rows of the following example:

<TABLE WIDTH="100%" BORDER=1>
<TR><TD ALIGN="LEFT">left</TD></TR>
<TR><TD ALIGN="CENTER">center</TD></TR>
<TR><TD ALIGN="RIGHT">right</TD></TR>
</TABLE>

(Prince 6.0r7)

The VALIGN attribute also appears to be ignored.

I think in this case it is because the rule in the default HTML style sheets is case sensitive, so it will only recognise "left", not "LEFT".

Changing the HTML to use lowercase values appears to work.

I would like to point out that, according to the specifications, this shouldn't be case-sensitive.
CSS 2.1 says: "The case-sensitivity of attribute names and values in selectors depends on the document language."
HTML 4.01 says: "[CI]: The value is case-insensitive (i.e., user agents interpret "a" and "A" as the same)."

Also, it appears that ALIGN and VALIGN aren't inherited from TR elements. While this is correct in CSS (vertical-align and text-align don't apply to table-row elements), in HTML these attributes do inherit. It seems like this can be fixed with some (or actually, a lot of) additional style rules for HTML, e.g:

tr[valign="top"] > td:not([valign]) {
	vertical-align:top;
}

And finally, ALIGN translates to text-align, which doesn't cover 100% of what ALIGN does in HTML. The following shows right-aligned in HTML, but left-aligned in Prince:

<table width="100%" border=1><tr><td align=right>
<table><tr><td>x</table>
</table>

I don't know what the best "fix" for that would be. I'd be tempted into saying:

td[align=right] > * {
	margin-left: auto;
}
td[align=right] > * > * {
	margin-left: 0;
}

but I'm sure that still has side-effects I'm not thinking of.

Yes, we need to add a case-insensitive attribute selector to implement HTML 4 properly in the default style sheets. The align and valign attributes are a bit tricky to get entirely right using only CSS, and at the moment we are still undecided as to whether we should add a small CSS extension to assist or implement these natively. I've added these issues to the roadmap.

Thank you. I think I can live with having to tweak the HTML to get the PDF output I want, but for the sake of standards-support I appreciate this being an item on the roadmap.

It's been a while but we have fixed this issue in the latest build by making these attribute values case insensitive in the default HTML style sheet.

It's impressive that you were able to keep track of this thread for over 10 years. Thank you for the follow-up!