427961 - Charts/reports should be able to use another font for i18n purposes

Status: RESOLVED DUPLICATE of bug 287682

(Bugzilla :: Reporting/Charting, enhancement)

Description

[A. Shimono [:himorin]]

Attachment: proposal

This is a patch from Bugzilla-ja codebase.
To show non-ascii gryphs at charts/reports, Bugzilla must (is needed to?) specify a suitable font to GD or graphviz/dot.

Comment 1

[Frédéric Buclin]

With no context, the patch is unreadable. When you say a suitable font, which font would be able to work with all Unicode characters? Assuming you can have anything as characters in Bugzilla, you cannot edit the param everytime you want to display a different string written in Unicode.

Comment 2

[Vitaly Fedrushkov]

(In reply to comment #1)
> With no context, the patch is unreadable. When you say a suitable font, which
> font would be able to work with all Unicode characters? Assuming you can have
> anything as characters in Bugzilla, you cannot edit the param everytime you
> want to display a different string written in Unicode.

per bug 287682 comment 12: still not sure this belongs to params.  Having things tunable is good, but we don't have parameters for html rendering fonts, we leave these to CSS instead.

And yes, we do not know universally good fonts now.  I created a 日本語 (and にほんご') component here: 

http://landfill.bugzilla.org/bugzilla30l10n/editproducts.cgi?action=edit&product=Bugzilla%20Localization

So we will try to find a font working with european and kanji and cyrillic.

Comment 3

[Vitaly Fedrushkov]

http://landfill.bugzilla.org/bugzilla30l10n/report.cgi?y_axis_field=&cumulate=0&z_axis_field=&format=bar&x_axis_field=component&query_format=report-graph&short_desc_type=allwordssubstr&short_desc=&product=Bugzilla+Localization&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Looks like we need to experiment with template/*/custom/reports/report-*.png.tmpl first

Comment 4

[Max Kanat-Alexander]

If it needs to be a bitmap font, there's always that latarcyrheb-sun16 font that Red Hat distros use for the terminal.

Comment 5

[A. Shimono [:himorin]]

(In reply to comment #1)
> With no context, the patch is unreadable. When you say a suitable font, which
> font would be able to work with all Unicode characters? Assuming you can have
> anything as characters in Bugzilla, you cannot edit the param everytime you
> want to display a different string written in Unicode.

Ah, yes. If whole user use one language, some font file on that language is ok. 
But if you use in some multi-language environment, you should specify a font file name which contains whole gryphs.
Such font file might be easy to make, with merging fonts in each language. (like fontconverter etc.)

(In reply to comment #4)
> If it needs to be a bitmap font, there's always that latarcyrheb-sun16 font
> that Red Hat distros use for the terminal.

I know that name used in SYSFONT parameter.
But, i don't know the actual file for that font package, i've not tried.

For Windows user, mskb #287247 will be help.
http://support.microsoft.com/Default.aspx?scid=kb%3ben-us%3b287247&x=6&y=15

Comment 6

[Vitaly Fedrushkov]

(In reply to comment #5)
> For Windows user, mskb #287247 will be help.
> http://support.microsoft.com/Default.aspx?scid=kb%3ben-us%3b287247&x=6&y=15

Looks like one should have MS Office license to use arialuni.ttf

Comment 7

[Semenenko Pavel]

(In reply to comment #0)
> Created an attachment (id=314555) [details]
> proposal

I tried this proposal and found it incorrect in png templates. So I create a new one (only to correct png templates, another in your proposal work good).
It fix some set_ font for different diagrams, and in some report cut "USE graph.." out "FILTER null.." section, we cant' define fonts before constructor of graph.
All this already start on my internal server and work good with Russian language.

Comment 8

[Semenenko Pavel]

Attachment: fix png templates♦

Comment 9

[A. Shimono [:himorin]]

# sorry for late response.

(In reply to comment #7)
> > Created an attachment (id=314555) [details] [details]
> > proposal
> 
> I tried this proposal and found it incorrect in png templates. So I create a
> new one (only to correct png templates, another in your proposal work good).
> It fix some set_ font for different diagrams, and in some report cut "USE
> graph.." out "FILTER null.." section, we cant' define fonts before constructor
> of graph.
> All this already start on my internal server and work good with Russian
> language.

I totally forgot about 'y' axis. So you're right.
For 'FILTER null', isn't it only for templates itself, but not for GD module?

So, should we merge these two patches into one, to make them better??

Comment 10

[Vitaly Fedrushkov]

What about having this landed in 3.6/4.0?

Comment 11

[Max Kanat-Alexander]

Well, somebody does have to post a patch and actually request review on it, but sure, we could have something like this for 4.0.

Why not just have Bugzilla always look in a particular directory for extra chart fonts and use those if necessary? It could even be inside the template/<lang> directory so you could ship it with a localization. (Or you could just ship DejaVu or Liberation or something like that...)

Comment 12

[Vitaly Fedrushkov]

Attachment: Patch v3, combined

Here's a cumulative patch against CVS HEAD.

Strange enough, I was unable to made it work on Windows.

Most common cause is:
http://search.cpan.org/~mverb/GDGraph-1.43/Graph/FAQ.pod#TrueType_fonts_don%27t_work_when_I_use_GD::Graph_from_a_CGI_program.

I have tried

[% IF Param('graphfontname') != '' %]
[%
  USE text = GD.Text;
  text.font_path('c:/windows/fonts');
  graph.set_title_font(Param('graphfontname'), 9);
  graph.set_value_font(Param('graphfontname'), 9);
%]
[% END %]

with no effect.

Any ideas?

Comment 13

[Vitaly Fedrushkov]

Probably the same problem: http://code.google.com/p/bugzilla-cn/issues/detail?id=17

Comment 14

[A. Shimono [:himorin]]

(In reply to comment #12)
> Created an attachment (id=372261) [details]
> Patch v3, combined
> 
> Here's a cumulative patch against CVS HEAD.
> 
> Strange enough, I was unable to made it work on Windows.

Could you attach the output of checksetup.pl or add perl and GD-related versions as comment?
I'll try to check what is the problem on my test server.
(After returning to Japan)

Comment 15

[Frédéric Buclin]

Comment on attachment 372261 [details] [diff] [review]
Patch v3, combined

>+++ 427961/Bugzilla/Config/Common.pm	2009-04-11 12:50:47.718750000 +0600

>+sub check_graphfontname {

Write check_graph_font_name.



>+++ 427961/Bugzilla/Config/DependencyGraph.pm	2009-04-11 12:53:09.296875000 +0600

>+   name => 'graphfontname',

Write graph_font_name.



>+++ 427961/template/en/default/reports/chart.png.tmpl	2009-04-11 08:13:36.859375000 +0600

>+[% IF Param('graphfontname') != '' %]

It's cleaner to write: [% IF Param('graph_font_name') %].


>+[%
>+  graph.set_x_label_font(Param('graphfontname'), 9);
>+  graph.set_x_axis_font(Param('graphfontname'), 9);
>+  graph.set_y_label_font(Param('graphfontname'), 9);
>+  graph.set_y_axis_font(Param('graphfontname'), 9);
>+  graph.set_title_font(Param('graphfontname'), 9);
>+  graph.set_legend_font(Param('graphfontname'), 9);
>+  graph.set_value_font(Param('graphfontname'), 9);
>+%]

You duplicate this code 3 times, which is bad. You should put this block in a separate template, e.g. report.html.tmpl, which is called by all PNG templates, AFAIK.

Comment 16

[Vitaly Fedrushkov]

(In reply to comment #14)
> Could you attach the output of checksetup.pl or add perl and GD-related
> versions as comment?

* This is Bugzilla 3.5 on perl 5.10.0
* Running on WinXP/.Net Build 2600 (Service Pack 3)

Checking perl modules...
Checking for              CGI.pm (v3.33)   ok: found v3.41
Checking for          Digest-SHA (any)     ok: found v5.47
Checking for            TimeDate (v2.21)   ok: found v2.22
Checking for            DateTime (v0.28)   ok: found v0.45
Checking for   DateTime-TimeZone (v0.79)   ok: found v0.8301
Checking for           PathTools (v0.84)   ok: found v3.2501
Checking for                 DBI (v1.41)   ok: found v1.607
Checking for    Template-Toolkit (v2.15)   ok: found v2.20
Checking for          Email-Send (v2.16)   ok: found v2.192
Checking for          Email-MIME (v1.861)  ok: found v1.861
Checking for Email-MIME-Modifier (v1.442)  ok: found v1.442
Checking for                 URI (any)     ok: found v1.37

Checking available perl DBD modules...
Checking for              DBD-Pg (v1.45)    not found
Checking for           DBD-mysql (v4.00)   ok: found v4.005
Checking for          DBD-Oracle (v1.19)    not found

The following Perl modules are optional:
Checking for                  GD (v1.20)   ok: found v2.41
Checking for               Chart (v1.0)    ok: found v2.4.1
Checking for         Template-GD (any)     ok: found v1.56
Checking for          GDTextUtil (any)     ok: found v0.86
Checking for             GDGraph (any)     ok: found v1.44
Checking for            XML-Twig (any)     ok: found v3.32
Checking for          MIME-tools (v5.406)  ok: found v5.427
Checking for         libwww-perl (any)     ok: found v5.814
Checking for         PatchReader (v0.9.4)  ok: found v0.9.5
Checking for          PerlMagick (any)      not found
Checking for           perl-ldap (any)     ok: found v0.39
Checking for         Authen-SASL (any)     ok: found v2.12
Checking for          RadiusPerl (any)     ok: found v0.13
Checking for           SOAP-Lite (any)     ok: found v0.69
Checking for            JSON-RPC (any)      not found
Checking for         HTML-Parser (v3.40)   ok: found v3.60
Checking for       HTML-Scrubber (any)     ok: found v0.08
Checking for Email-MIME-Attachment-Stripper (any)     ok: found v1.316
Checking for         Email-Reply (any)     ok: found v1.202
Checking for         TheSchwartz (any)      not found
Checking for      Daemon-Generic (any)      not found
Checking for            mod_perl (v1.999022)  not found

Comment 17

[Vitaly Fedrushkov]

Attachment: Screenshot

Note how texts are displayed byte-coded (not 'missing glyphs' which commonly get replaced by squares in True Type).

Looks like we disagree with GD in some UTF-8 handling.  Bug 457524 comes to mind.

Comment 18

[A. Shimono [:himorin]]

(In reply to comment #17)
> Created an attachment (id=372660) [details]
> Screenshot
> 
> Note how texts are displayed byte-coded (not 'missing glyphs' which commonly
> get replaced by squares in True Type).
> 
> Looks like we disagree with GD in some UTF-8 handling.  Bug 457524 comes to
> mind.

With this screenshot, I think GD is not using the specified font file.
Now, I'm starting my test env. So, I think I can test this soon.

Comment 19

[A. Shimono [:himorin]]

Attachment: test script for GD

This is test script for GD module's ttf option.
If false, you cannot use ttf font file for GD.

In my test server, this script outputs 'false' on Windows.

Comment 20

[A. Shimono [:himorin]]

Sorry for late responce.

So, my proposal is
1. use the basic method in the SnowyOwl's patch.
2. add additional environment check routine to check_graph_font_name which arises some error when the GD module doesn't support ttf font.

Is this reasonable?

Comment 21

[A. Shimono [:himorin]]

*comment*

As part of tests for bug 542464, this bug will be resolved for dependency graph with using graphviz 2.22 (or higher). Don't do recurring test for older versions.

http://landfill.bug-ja.org/ja-304/showdependencygraph.cgi?id=1&showsummary=on&display=tree&rankdir=TB

Comment 22

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

Comment 23

[Frédéric Buclin]

No need for a separate bug. Bugzilla supports UTF8 and all installations should now use UTF8 by default.