Font styles on Mac and Windows

[Buckie]

Vaughan, I don't know if you're referring to my posts or not, but I'll respond anyhow. My database solution is working just fine now save for this fonts issue. And the problem is that I'm not the one to call the shots on the form design. The person who designed those awesome agreement forms with a multitude of font styles won't budge, they want it styled that way, end of story. They also want to make edits without much effort, perhaps to add even more style! So unfortunately that's how it is.

comment,

thanks for the getascss tip! It feels like a better solution than doing it with hacked fonts.

I started by trying to extract the data from that large block of text on a layout by using GetLayoutObjectAttribute. I use it like this in a calculation field: GetLayoutObjectAttribute ( "mybox" , "content" ) to which I get "This number cannot be evaluated." The sample syntax for that Get is confusing - some examples list a semicolon and other just a comma. I get the error with the comma but with the semicolon there's neither an error nor any result. I've tried other attributes, such as "bounds" and still get an empty field. Possibly missing something obvious? I did name the object in the Inspector in the 'Position' tab.

[Buckie]

comment,

wow! indeed it does work that way! That is totally weird! So it seems like a good way to do it, just need to add some AppleScript to print the result and delete the file afterwards. Nice!

[comment]

The default separator between function separators is semi-colon, but it may change if your application is localized. If in doubt, select the function from the top right corner - it will be inserted in the correct prototype. Make sure the result is set to Text (and you probably should make it unstored).

just need to add some AppleScript to print the result and delete the file afterwards.

If you save it in the temp folder, you don't even need to delete it.

[Buckie]

Yes, it was a d'oh moment - the calculation wasn't unstored. Let's see if I can come up with a working AppleScript now... But actually I do like the GetAsCSS approach too.

[comment]

actually I do like the GetAsCSS approach too.

LOL, it would make a great summer project. The AppleScript, OTOH, should take about 15 minutes including testing...

[Buckie]

Oh yeah. I kinda forgot that there's no SETwithCSS. So you're right.

[Buckie]

It was a surprisingly simple task. Can anyone test it for me as I have no printer right now?

The script is like this:

Save Records as PDF filemac:/Macintosh HD/tmp/printout.pdf

Perform AppleScript do shell script "lpr /tmp/printout.pdf"

[Buckie]

And to finish this thread, yes, the method above works. It's best to find out the drive name beforehand, so...

Set Variable [$volumename; Value:Get ( SystemDrive )]

Save Records as PDF filemac:$volumename/tmp/printout.pdf

Perform AppleScript do shell script "lpr /tmp/printout.pdf"

There are various options you can pass to lpr, like duplex printing or rear tray printing.

You can find out all the options for your printer by typing

lpoptions -l

in the terminal and then look for pairs that look like

Printer's Specific Value/Human-readable description: *value1 value2 value3

Then you set Printer's Specific Values using lpr's -o flag like so

lpr -o EPIJ_FdSo=0 -o Another_option=2 file_name_to_print

with the first being a string telling Epson B-300 printer to source paper from its rear tray.

Thanks a lot to comment for helping me with this one and everyone else who contributed!!

[Jaesonborn]

Thanks to everybody who contributed in this thread, really helped me a lot :)

[qube99]

We solved this problem in the typesetting/printing industry long ago. The problem is most screen fonts didn't match the printer fonts. In FMP the problem is the Mac screen font doesn't match the Windows screen font.

We started off by only guaranteeing output using Adobe postscript fonts. The final solution the industry adopted was to embed the fonts in the documents. Adobe came up with this and it works great.

Perhaps we could ask FM to start embedding fonts in our solutions.

The historical reasons are based on the industry's adoption of Adobe postscript as the standard page description language. Countless millions of dollars were invested in postscript raster image processors and film output devices. But Microsoft refused to license Adobe and Mac postscript took 99.9% of the desktop publishing market. Microsoft finally adopted TrueType (licensed from Apple) but in usual Microsoft fashion they munged it a bit so it doesn't match Apple's TrueType.

If you use the same TrueType font on both platforms they match. Asking a client to install a font is no good, so embedding became the answer for cross-platform font matching.

The simple workaround for now is to design on the PC and use Verdana. This cripples fontography severely but it's all we have until we get embedded fonts.

HTML5 and CSS3 call for embedded fonts for web pages. Designers were ecstatic at the new standard. The problem now is to get all the browser designers to agree on a font technology, which they have bitterly warred over, so no satisfactory web solution has been achieved.

I'd suggest TrueType embedding for FMP since both platforms support it.

[johnlewisdesign]

Summary: do the design on the Windows side. Fonts look bigger and take up more room in Windows than on Mac.

In theory, yes. but be sure to leave a bit of extra text box or you will see things like Tahoma on Mac cut off. I usually leave a character width or two.

[LaRetta]

It happens with Verdana and some others as well. But that is what Vaughan is saying ... If you design on Windows then the fields are large enough that displaying them on Mac show the entire font but if they are designed on Mac you must increase field height or they cut off.

And this is 'a few px' PER LINE. If a Mac person has a large text box then an entire last row of text (or more) can disappear on Windows.