pdf export problem

[David Elbert]

Hello All-

I have been having problems exporting notebooks to pdf and was hoping
someone might have some insight. I submitted a support request to
Wolfram, but have not heard back.

Quick background: Mathematica 7.0.0; Macintosh Front End (OS X Leopard 10.5.6).

Quick summary: I am writing "handouts" for distribution in a math/
stats class. Some characters disappear when converting to pdf.
Example that has been vexing me lately is the less-than-or-equal-to
sign (unicode character 2264, I think). I just get blank spaces in
its place.

My theories (obviously wrong or I wouldn't be here asking!): I
thought it was a problem with font installations, but I have tried
different fonts without success. I also have noted that the problem
occurs when the cells are "text" style, but goes away if I make the
cell "equation" style. I can't decide if there is a problem in the
style definitions, a bug that improperly defines fonts (and/or misses
embedding) into pdf, or something to do with "high" unicode characters.

Apologies if my perusal of the archives has missed another discussion
of this issue, but thanks to anyone who can offer any insight or
help. I thought such font problems were well in my past, but no such
luck.

Thanks-

David

David Elbert
Department of Earth and Planetary Sciences &
Environmental Science and Policy Program
Johns Hopkins University
3400 N. Charles St
Baltimore, MD 21218

elb...@jhu.edu

[peter]

can you send me an example a notebook you are having problems with. We use
macs so may be able to help.
Peter

2009/3/27 David Elbert <elb...@jhu.edu>

--
Peter Lindsay

[hayes...@gmail.com]

Hi David:

Not much in the way of help here, but moral support. I, too, have had
problems exporting notebooks to PDFs with Mathematica (both 6 and 7).
A couple of things:

[1] For obvious reasons, transparency doesn't work well, but if you
save using the "bitmap" that will solve that problem.

[2] I've contacted Mathematica about the font mappings. Even The
Mathematica Journal doesn't print/export correctly for me. For some
reason it always wants to use Courier, for everything but Times,
despite having verified that all other fonts installed correctly. Some
workarounds,

File -> Printing Options -> Working

might help. Weird thing is, if I use "working," as opposed to
"printout," the fonts map properly, but figures wind up being cut off
and the text wrap doesn't work so well. You also may want to go into
the Options Inspector and hardcode the PageMargins for the "Printout"
option (compared to "Working"). When I get home from work this evening
I will post the actual numbers and option names you can try as
provided by Wolfram.

Hope that helps. If I find anything else that works, I will be sure to
post.

Cheers,

t.

PS - I use a Linux computer (Kubuntu 8.04), and you?

On Mar 27, 6:35 am, David Elbert <elb...@jhu.edu> wrote:
> Hello All-
>
> I have been having problems exporting notebooks to pdf and was hoping
> someone might have some insight. I submitted a support request to
> Wolfram, but have not heard back.
>

> Quick background: Mathematica 7.0.0; Macintosh Front End (OS X Leopard=

10.5.6).
>
> Quick summary: I am writing "handouts" for distribution in a math/
> stats class. Some characters disappear when converting to pdf.
> Example that has been vexing me lately is the less-than-or-equal-to
> sign (unicode character 2264, I think). I just get blank spaces in
> its place.
>
> My theories (obviously wrong or I wouldn't be here asking!): I
> thought it was a problem with font installations, but I have tried

> different fonts without success. I also have noted that the problem =

> occurs when the cells are "text" style, but goes away if I make the
> cell "equation" style. I can't decide if there is a problem in the
> style definitions, a bug that improperly defines fonts (and/or misses
> embedding) into pdf, or something to do with "high" unicode characters.
>
> Apologies if my perusal of the archives has missed another discussion
> of this issue, but thanks to anyone who can offer any insight or

> help. I thought such font problems were well in my past, but no such =

[Bob F]

On Mar 27, 4:35 am, David Elbert <elb...@jhu.edu> wrote:
> Hello All-
>
> I have been having problems exporting notebooks to pdf and was hoping
> someone might have some insight. I submitted a support request to
> Wolfram, but have not heard back.
>

> Quick background: Mathematica 7.0.0; Macintosh Front End (OS X Leopard=

10.5.6).
>
> Quick summary: I am writing "handouts" for distribution in a math/
> stats class. Some characters disappear when converting to pdf.
> Example that has been vexing me lately is the less-than-or-equal-to
> sign (unicode character 2264, I think). I just get blank spaces in
> its place.
>
> My theories (obviously wrong or I wouldn't be here asking!): I
> thought it was a problem with font installations, but I have tried

> different fonts without success. I also have noted that the problem =

> occurs when the cells are "text" style, but goes away if I make the
> cell "equation" style. I can't decide if there is a problem in the
> style definitions, a bug that improperly defines fonts (and/or misses
> embedding) into pdf, or something to do with "high" unicode characters.
>
> Apologies if my perusal of the archives has missed another discussion
> of this issue, but thanks to anyone who can offer any insight or

> help. I thought such font problems were well in my past, but no such =

> luck.
>
> Thanks-
>
> David
>
> David Elbert
> Department of Earth and Planetary Sciences &
> Environmental Science and Policy Program
> Johns Hopkins University
> 3400 N. Charles St
> Baltimore, MD 21218
>
> elb...@jhu.edu

David,

Well I can see your problem now. The difference from what I did and
what you did (and this is a guess), is that I created my test cells
with the less than as an Input cell and then changed the style to
Text. So I created another test case with the cell being created as a
Text cell initially, and sure enough it shows the problem.

So two workarounds are available:

1. Create your cells as Input and convert them to Text with the Format/
Style/Text command
2. Use another type of less than, e.g. \LessSlantEqual which does not
seem to have the same problem.

Wolfram, you have a bug - IMHO. Because the problem does not occur in
both types of Cells (Input and Text), I sure would guess the problem
is Mathematica's and not a PDF/Adobe problem.

-Bob

[AES]

In article <gqkusk$48q$1...@smc.vnet.net>, hayes...@gmail.com wrote:

> Hi David:
>
> Not much in the way of help here, but moral support. I, too, have had
> problems exporting notebooks to PDFs with Mathematica (both 6 and 7).

Used to be a gotcha in exporting graphics with added Labels to PDF. The
labels created by the Label command showed up fine in the notebook
output cell viewed on screen, but appeared in the exported PDF file
enclosed in unwanted double quotes ("My Label").

There was some arcane option you had to set to present this; don't know
what the present situation may be.

Also, in certain graphics plots exported as PDFs and then opened with
some (but not all) Adobe apps, certain lines would appear enormously
thickened. Selecting the lines in Illustrator and resetting their
thickness would cure the situation.

Never resolved, at least so far as I know, whether this was a Wolfram or
Adobe problem.

[David Elbert]

Thanks to the several users who replied off-group. I now have an effective work around. Since I am working on a Mac I can use the print command to then save as a .pdf file. I had initially missed this option because that route usually provides a standard save-as dialog that includes the .pdf extension. In Mathematica 7.0.0 the dialog defaults to using .nb as the extension... so I thought it simply didn't work. It does work. It just doesn't use the proper extension.

I continue to have the problem using the direct Save As dialog to export to .pdf so perhaps there is some bug there, but at least I can avoid it. Interestingly, the problem is there for cells with "text" style, but the same cells changed to "input" or "equation" produce fine pdf.

So... problem not completely solved, but sidestepped.

-David

[hayes...@gmail.com]

Here is some more advice. A snippet from Wolfram....

For example, in the TMJ stylesheet, you can edit the Working style to
understand printing margins by adding the following options to the section
Style Environment Names -> Working: (use Ctrl-Shift-e to open the
section)

PageWidth->PaperWidth,
PrintingOptions->{"PageSize"->{490, 720},
"PrintingMargins"->{{0, 0}, {82, 56}}},

If you are working on a custom stylesheet, you can copy the Style
Enviornment Names section out of Core.nb, paste it into your stylesheet,
and make the changes there.

Adding these options and setting the Printing Environment to Working will
allow you to make PDFs that more closely match what you see on the screen.

Cheers,

t.

[peter]

HI David

the secret is as follows [ mac ]:

File
Print
PDF
Save as PDF

Peter

[ragfield]

> A couple of things:
> [1] For obvious reasons, transparency doesn't work well, but if you
> save using the "bitmap" that will solve that problem.

Perhaps these reasons are less obvious than you think. Transparent
graphics export to PDF fine for me. Could you explain what you mean
by this?

> Wolfram, you have a bug - IMHO. Because the problem does not occur in
> both types of Cells (Input and Text), I sure would guess the problem
> is Mathematica's and not a PDF/Adobe problem.

Please make sure to report any issues you believe to be bugs to
Wolfram Research <http://support.wolfram.com/submitabug.cgi>. As has
been stated repeatedly on this forum, a mention here is not sufficient
to ensure the issue is tracked and fixed.

-Rob

[hayes...@gmail.com]

Hi Rob:

My comments are below....

On Mar 31, 5:14 am, ragfield <ragfi...@gmail.com> wrote:
> > A couple of things:
> > [1] For obvious reasons, transparency doesn't work well, but if you
> > save using the "bitmap" that will solve that problem.
>
> Perhaps these reasons are less obvious than you think. Transparent
> graphics export to PDF fine for me. Could you explain what you mean
> by this?

I can only comment on this one, the posting below from someone else.
>From the Documentation Centre on Opacity:

Opacity
Opacity[a]
is a graphics directive which specifies that graphical objects which
follow are to be displayed, if possible, with opacity a.
Opacity[a, color]
uses the specified color with opacity a.
MORE INFORMATION
* Opacity runs from 0 to 1, with 0 representing perfect
transparency.
* If an opacity a object with color c1 is placed in front of an
object with color c2, the resulting color will be the blend ac1+(1-a)
c2.
* If red and blue with opacity 0.5 are combined, the result is
purple=97not black, as it would be with physical monochromatic filters.
=BB
* Opacity works in both 2D and 3D graphics.
* It may take significantly longer to render 3D graphics that
involve transparent surfaces.
* Graphics that involve transparency may need to be printed as
high-resolution bitmaps.

So, this last one is what I meant. And, from my experience, is true.

Cheers,

t.

[ragfield]

On Apr 1, 2:53 pm, hayes.ty...@gmail.com wrote:
> * Graphics that involve transparency may need to be printed as
> high-resolution bitmaps.
>
> So, this last one is what I meant. And, from my experience, is true.

Printing isn't quite the same thing as exporting to PDF. The PDF
format supports transparency. Mathematica produces PDF files with
transparency. These files can be displayed correctly on screen.
Anything that is printed is rasterized at some point (whether that's
explicitly done by Mathematica, the printer driver, or the printer
itself is irrelevant). There are other reasons why Mathematica may
rasterize a graphic saved to a PDF file (VertexColors), depending on
your preferences settings.

-Rob