Hi

I have a client using Helevtica55Roman for a report, I am re-creating a
replicate report in a new FileMaker file to add to their (eslewhere
developed) solution. The report prints a PDF to desktop.

I have sourced the font from a couple of places and reinstalled (free;
couldn't find a pay for version); but same problem, the 'o' letters do
not print on by Mac OSX.6 FM11Adv ; I haven't heard back from the client
testing yet ( probably will work for them).

There is also a message about license


<<
A font in this document is not licensed for embedding without permission
from the legal owner or font vendor. Depending on the font, blank text
may appear in the output file.
Well, there is only the Helvetica55Roman, and it was supposed to be
free, no indication of licensing requirements.


Thoughts?


Just for your amusement and edification, the solution is a 49 file set,
multiple tables per file; one table I looked at yesterday: 921 fields.

In article <jghq8o$d4m$1 (AT) speranza (DOT) aioe.org>, cortical
<cb (AT) corticaldata (DOT) com.au> wrote:

Are you sure it's that font causing the error and not another one? Try
making a new layout that you know uses only that font and make a PDF.
(Fonts embedded in logos for example can cause problems without you even
relaising they're being used.)

If it is that font, then try remove the "Helevtica55Roman" font from the
computer (quit and restart FileMaker, or even reboot the computer to make
sure it's gone). FileMaker will automatically use a close substitute which
may be unnoticeable.

If the automatic substitute doesn't work, then your best option is to
simply use normal Helvetica (I'm almost certain it's still one of the
Mac's default system fonts). You may be able to get away with just using
it on the new report, otherwise you'll have to go through all the Layouts
changing it. If the client is using a Windows computer, FileMaker may well
substitute the font back - not that anyone would notice the difference
anyway.

Helpful Harry )

On 4/02/12 10:38 AM, Helpful Harry wrote:
Yes


Try
There are no logos, this is a file that basically has a search layout
and a report layout. And the initial version of the layout, with
everything working, before I updated it for their corporate
Helvetica55Roman had no problems outputting A PDF.


As I indicated the client already uses Helevtica55Roman. The requirement
is to stick with their corporate image and expensive Agency specified
design parameters. Although FM is incapable of specifying 0.5 font sizes
such as 5.5 or 10.5.



See prior paragraph.

You may be able to get away with just using

It is a font on the report layout ( a Real Estate brochure), not one for
data entry.

In article <jginj6$a0t$1 (AT) speranza (DOT) aioe.org>, cortical
<cb (AT) corticaldata (DOT) com.au> wrote:
Which proves the point that particular font is the problem. Just use
normal Helvetica and it should work - any differences between the two
fonts will be extremely minor and unnoticeable anyway.

There could be something on the layout using a different font. You could
try doing a Select All in Layout Mode and changing the font to somthing
else entirely (even a dingbat font), quitting FileMaker, then going back
in and changing the font back again, but I doubt it will make any
difference - it really a font issue and not a FileMaker one.

The only other possbility is to get a copy of the same font file(s) from
their computers, assuming it works there.

Helpful Harry )

On 5/02/12 7:27 AM, Helpful Harry wrote:

I never had any doubt that it was the font.




Just use

That's why it is a different font is it Harry?
It is a client specification. The client and the agency use the font
without issue.



There isn't.


You could
Q: Did I not indicate previously that the layout printed to PDF
correctly, before redefining the fonts to Helvitac55Roman?
A: I did.


Well not a particularly professional way to to approach the issue. They
presumably got it from somewhere, somewhere that was capable of
supplying a font that works. So not the only other possibility.

This is Oz Harry, not the land of Nod.

End of transmission.

In article <jgkl93$n54$1 (AT) speranza (DOT) aioe.org>, cortical
<cb (AT) corticaldata (DOT) com.au> wrote:

This is not a fFileMaker problem - it's a font issue. I've given you a
solution, it's not my problem if you don't want to use it. If you're not
going to accept answers, then don't bother asking questions. I won't be
wasting any more of me own time with you again. \

Helpful Harry )

on 5/02/2012, Helpful Harry supposed :
of their eyes 8-o
Harry I thought you were particularly patient.

--
John G

In article <slrnjis9aq.1lcb.t-usenet (AT) ID-685 (DOT) user.individual.de>,
traut (AT) gmx (DOT) de wrote:
The "customer" will not be able to tell the difference between
HelveticaXYZ97 and normal Helvetica - and if there's a problem with that
font, then they should be told so. If the font (supposedly) works on the
customer's computers, then why not get a copy of the font from them rather
than download dodgey versions from the Internet??

There's something very peculiar going on that is best to steer well clear
of, as well as some snotty person who won't even listen to answers or try
thing you give them as suggestions.

Helpful Harry )

On 6/02/12 8:14 AM, Martin Τrautmann wrote:
The font is mandated by the client; it is a 'corporate' font, they have
been using it for quite some time, it is part of the corporate style for
which they paid significant money to a PR agency to develop as part of
their corporate image.

The PDF files go to a professional print agency for assembly and
publication. So being a professional print agency they notice deviations
from specification.

To Harry; try reading my requirements.

On 5/02/12 5:14 PM, Martin Τrautmann wrote:
Quite so.



routine save records as pdf form a script



It needs to be cross platform. Only tested on a mac on this point



only option 1 is viable