Right, a bit more work in this one. There were various problems.
First of all note that placing text cleverly in most of the graphics
modes (Tk, OpenGL, PDF) is a pain because these people never give you an
easy way to calculate the bounding box of text (PostScript does, that is
the exception). So I've cobbled together an approximation in the cases
where you cannot get at the exact result. That was a semi-recent addition
to the PDF output but I forgot to change the C world version, just the
Python world one, and the former is more important, so I've fixed that
now.
Secondly, it turns out that the PostScript font setting was still being
ignored for the peak annotations. So that is fixed now.
Thirdly, the output scaling was being ignored for the font setting. This
was just an oversight. (I usually print out at 90% so never noticed.)
So I've added in that the font sizes are now multiplied by the output
scaling factor.
I've done a few tests and the fonts more-or-less seem ok at various output
scalings, in both PS and PDF. But because of the bounding box hassles
this is bound not to be a perfect replication between all graphic modes.
This affects five files: ps_handler.c, pdf_handler.c, PrintHandler.py,
Pdf.py and WindowDraw.py. You will notice that two of those files are C
code. The Update server code was changed for version 1.0.13 so that in
theory this C code should automatically compile for you when you do the
update. If for some reason it does not then you will have to go into
"ccpnmr1.0/c" and type "make" before the changes will work. (Now how do
you tell if it has compiled? Hopefully the Python bit of the update
script will not crash and hopefully it will put some compilation messages
out to the screen in the shell you are running Analysis from. If not,
then you can check that ccpnmr1.0/c/memops/global/PsHandler.so and
PdfHandler.so were last updated at approximately the current time.
Typing "make" in ccpnmr1.0/c should not hurt, but it would be useful to
know if people are getting a compilation message on the screen.)
Wayne
On Mon, 12 Feb 2007, Patrick van der Wel wrote:
> It also seems to me that both the PS and PDF files are improved over the
> previous times I tried to use them. In the absence of peak labels, the
> resulting spectra look nice, but any peak labels do look a bit funny.
> There are a couple of issues/questions....
>
> 1. When I 'scale' the figure (say to 50% vs 100%), it does not appear to
> affect the font size. Is this on purpose? In general, the fonts appear
> always larger than they are inside Analysis. Is there some configuration
> option that I am not aware of, that controls this?
>
> 2. There is something funny with the label positioning in the PS vs PDF
> files: It looks like the 'origin' to which the text is justified/lined
> up, is different between the two formats. In the PS files, the labels
> are positioned similarly to what one sees inside Analysis, either
> left-justified or right-justified to the end of the triangular arrows,
> depending on the direction the latter are pointing. However, in the PDF
> the text appears always left-justified and therefore sometimes lines up
> rather poorly with the 'arrows'.
>
>
> Patrick
>
> Wayne Boucher wrote:
> > Oh right, it didn't seem to do that for me. But if it does for you then
> > that's good news.
> >
> > Wayne
> >
> > On Mon, 12 Feb 2007, Murali Vadivelu wrote:
> >
> >
> >> Dear Wayne,
> >>
> >> Though it complains, it produces the required output without much
> >> trouble. So these errors/warnings are only a minor glitch.
> >>
> >> Many thanks.
> >>
> >> Best,
> >> Murali.
> >>
> >> On 12 Feb 2007, at 14:29, Wayne Boucher wrote:
> >>
> >>
> >>> Hello,
> >>>
> >>> The good news is that I solved the direct problem found by Murali
> >>> on the
> >>> PDF front (and fix is on the update server). (Well, I also fixed
> >>> another
> >>> unrelated bug whereby if you said "no" to overwriting a pdf/ps file
> >>> you
> >>> got an exception.)
> >>>
> >>> The bad news is that pstoedit just falls over a line later.
> >>>
> >>> I installed ghostscript and pstoedit and found that the error
> >>> Murali found
> >>> was output from postscript. So it seems that ghostscript is using
> >>> postscript to parse the PDF file (unbelievable, but what the
> >>> heck). And
> >>> debugging postscript is even harder than debugging anything else. But
> >>> eventually I figured out that what it was complaining about had
> >>> nothing to
> >>> do with the 20-byte size of the xref table lines, it was because the
> >>> number of entries in that table was one more than was being reported
> >>> (clever, eh), so it was expecting an "end of table" line and
> >>> instead found
> >>> another entry in the table.
> >>>
> >>> Unfortunately pstoedit is now complaining about an invalid font, i.e.
> >>> Times-Roman, but I suspect it would complain about Courier and
> >>> Helvetica
> >>> as well. I found another independent PDF file lying around on my
> >>> computer
> >>> (the Hibernate reference manual) that does pretty much exactly what
> >>> we do
> >>> (except that it uses more variations of the standard fonts). (For some
> >>> reason most PDF files fail to use the standard fonts, perhaps
> >>> because they
> >>> are too well-known.) And pstoedit falls over on that file as well,
> >>> for
> >>> the same reason. So my guess is that pstoedit doesn't like these
> >>> standard
> >>> fonts that Adobe says should be guaranteed to exist in any
> >>> implementation.
> >>> (Well, it might be ghostscript that is causing the problem.)
> >>>
> >>> So we are not much better off, although the PDF output should pass
> >>> through
> >>> more (i.e. non-pstoedit) software now.
> >>>
> >>> Wayne
> >>>
> >>>
> >>>> On Fri, 9 Feb 2007, Murali Vadivelu wrote:
> >>>>
> >>>>
> >>>>> pstoedit -f xfig HSQC_Folded_LF.pdf HSQC_Folded_LF.fig
> >>>>> pstoedit: version 3.44 / DLL interface 108 (build Oct 2 2006 -
> >>>>> release build - g++ 4.0.1 (Apple Computer, Inc. build 5363)) :
> >>>>> Copyright (C) 1993 - 2006 Wolfgang Glunz
> >>>>> **** Warning: xref subsection header has extra characters.
> >>>>> **** Warning: An error occurred while reading an XREF table.
> >>>>> **** The file has been damaged. This may have been caused
> >>>>> **** by a problem while converting or transfering the file.
> >>>>> **** Ghostscript will attempt to recover the data.
> >>>>>
> >>>>> **** This file had errors that were repaired or ignored.
> >>>>> **** Please notify the author of the software that produced this
> >>>>> **** file that it does not conform to Adobe's published PDF
> >>>>> **** specification.
> >>>>>
> >>>>>
>
|