[#GLIFFY-183] Published fonts don't match fonts in Gliffy client

Gliffy Product

Published fonts don't match fonts in Gliffy client

Created: 19/Apr/06 07:32 PM Updated: 24/Jun/08 04:39 PM

Component/s:

Core - Image Transcoding, Confluence Plugin Integration

Affects Version/s:

None

Fix Version/s:

None

Security Level:

Anyone may view

Description

« Hide

Since the fonts in Java aren't exactly the same as the device fonts, many of the published fonts don't look even close to those seen in the Gliffy client.

All

Comments

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Chris Kohlhardt - 05/Dec/07 11:06 AM

Also effects Confluence plugin since transcoded images are used in wiki pages.

Possible solution is to create a flash based viewer which will render fonts exactly the same. The only problem with a flash based viewer is that we don't know if we'll be able to print.

[ Permlink | « Hide ]

Pershin Y. - 06/Dec/07 02:51 AM

Chris, thanks for quick respond!

printing in confluence is special page mode
as temporary solution you can generate png in printing mode and swf in view mode
or add special parameters to {gliffy} macro:

Image	means
(default)	png in both modes
svg	svg in view mode
swf	swf in view mode( I'll use this )
...

ImagePrint	means
(default)	= Image
svg	svg in print mode
swf	swf in print mode
...

The following parameter can also be a new property of any gfx object (along with such properties, as width, font and height)

Anti-aliasing	means
(default)	-
full	full image anti-aliasing in all modes
onresize	anti-aliasing only for reduced sizes ( I'll use this)
gfxonly	text in 100% is never anti-aliased
...

[ Permlink | « Hide ]

Chris Kohlhardt - 06/Dec/07 11:14 AM

I believe the last time I looked, Confluence doesn't offer a way to detect the 'print mode' from within the Macro. Unfortunately, this means that we wont know when a user is in print mode.

We might be able to use stylesheets to help with this, since I believe some browsers can be directed to use a different stylesheets when printing. Some info here:

http://www.alistapart.com/stories/goingtoprint/

[ Permlink | « Hide ]

Pershin Y. - 06/Dec/07 03:00 PM

I think, CSS is right way, but it is indended to solve other aspects of printing problems.

Howewer, there is Visibility plugin with macro hide-if
http://www.customware.net/repository/display/AtlassianPlugins/hide-if
one of it's option is display=printable...

this plugin parses page URL parameters
I think, you should not do this, there is simplest solution

{hide-if:display=default}
{gliffy:Image=png}
{hide-if}
{hide-if:display=printable}
{gliffy:Image=swf}
{hide-if}

One more question about CONFLUENCEPLUGINSUPPORT-34
OK, fonts is a problem. But the radio button is very damaged too.... Maybe there is also gfx zooming problems when drawing by Java methods?
Is JVM can be set up to solve such problems? Maybe I should upgrade SUN JVM to 1.6 ?

[ Permlink | « Hide ]

Pershin Y. - 07/Dec/07 02:11 AM

CONFLUENCEPLUGINSUPPORT-34 once again
When printing my diagram from the editor, there is also small dot printed at the top-left corner of each element's bounding rectangle