Hi Ghost...
If you're talking about the Linux TTF, it works just fine, unfortunately it's not an exact match, so in order to get Times New Roman to work as advertised I might have to put some rather "dubious" code in, i.e. hunt down any text that "starts with"
number or find space + 0-9 and then stick an "i" in front in white..that sort of "dubious" thing.
The Time New Roman problem (and other fonts that are on both the IIS 7.5 box where the documents are created and the print servers where they are spooled) is quite baffling.
These are examples of the issue.
2 people went to market...the text comes out in Times, the number comes out in some bold san serif.
I went to the market on 12/12/2012 to see some pigs...shows the same problem
I went .2 the market on .12/12/2012......shows the same problem
I went t2 the market on i12/12/2012...all renders as Times.
In a nutshell, if the char preceeding the number is a-z the numbers are rendered correctly, otherwise they come out as bold san serif.
If I use, say for example Garamond (which isn't on the print server) then the whole everything renders correctly in Garamond. Same thing with all other fonts I tried. if both are on both servers then you get the problem. We have a mix of printers from
various manufacturers hanging off the print servers and the same thing happens on all of them so it's not a printer driver problem.
Everything renders correctly from a print out from the XPS viewer.
The exact architecture is that browser Ajax requests are fired at the doc builder service on an IIS box which builds the documents, puts them in an SQL database as byte arrays and returns success. Depending on the user's location and printer
spec, a new Ajax request is then sent to another IIS box (which is either local or remote to a print server) to print out the documents on location specific printers. The reason for doing it this way was to avoid Kerberos issues that would occur in a double
hop to a remote print server. Note: this is not my domain and I have no control over maintenance, but a Kerberos failure would result in badness, so it's been avoided. Therefore jobs that don't need an exact user, use a domain app pool account and jobs that
do require a specific user go to a service on the print server. Either way the same issue arises.
I though the problem was with my code, but the MS example XPS documents show the same issue.
XPS creation is by GemBox.Document from docx templates and Gembox saw the same issue on their servers when I brought this problem up with them. They put a fix in that partially resolved the matter from their standpoint, but it didn't make any difference
in my architecture.
HTH
