After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 622210 - Hebrew is exported at HTML entities instead of Hebrew UTF-8 chars
Hebrew is exported at HTML entities instead of Hebrew UTF-8 chars
Status: RESOLVED INCOMPLETE
Product: GnuCash
Classification: Other
Component: Reports
2.2.9
Other Linux
: Normal normal
: ---
Assigned To: gnucash-reports-maint
gnucash-reports-maint
Depends on:
Blocks:
 
 
Reported: 2010-06-20 17:11 UTC by Lior Kaplan
Modified: 2018-06-29 22:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Lior Kaplan 2010-06-20 17:11:17 UTC
Hi,

I use Hebrew in my GnuCash account names, and used Hebrew in the report title and company name.

While exporting to HTML, I got the Hebrew exported as HTML entities instead of regular (UTF-8) Hebrew. Inside GnuCash, the Hebrew looks just fine.

Example:
<B>&#1506;&#1502;&#1493;&#1514;&#1514; &#1492;&#1502;&#1511;&#1493;&#1512; &#1491;&#1493;&#1495; &#1499;&#1505;&#1508;&#1497; 12/31/2009</B>

instead of 
<b>עמותת המקור דוח כספי 12/31/2009</b>

This is not an HTML encoding isse. The problem is in the HTML source itself.
The HTML already have a meta tag to display UTF-8:
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">

Step to reproduce:
1. View a report.
2. Edit the company name and report name to include Hebrew (and probably any non-latin language).
3. export the report to HTML.
4. View the HTML source.

Kaplan
Comment 1 Lior Kaplan 2010-06-20 18:56:00 UTC
AFIAK this isn't the problem as appears in #616606.

Kaplan
Comment 2 Andreas Köhler 2010-09-01 19:42:15 UTC
What is the bug about? I created an html file with the meta and b tags above, loaded it in firefox and it displayed hebrew characters (I could not tell whether they are all correct though).
Maybe a sample file would help me.
Comment 3 Lior Kaplan 2010-09-01 19:58:30 UTC
The web browser can show the HTML entities correctly. The problem is that humans can't really handle HTML files where all characters are HTML entities instead of regular text.

Let's say I'd like to edit the company name in the example above. I should be able to open the HTML file and just edit it as any text file. On the text in the example, I need to start figuring out what character is printed for &#1492; (or any other entity) in order to fix a typo or what ever.

The idea of exporting reports to HTML isn't only the format, but also the ability for humans to read and edit it.
Comment 4 Carsten Rinke 2013-04-27 15:45:37 UTC
From my point of view, this bug does now describe faulty behaviour but rather and enhancement request.
So I propose to change the severity to ENH.
Comment 5 Lior Kaplan 2013-04-27 15:51:54 UTC
Having an editable HTML code, due to entities instead of text is a problem for non English users. I can't take the HTML export and adapt it to something else (from correcting a spelling mistake to reordering the sections) as I can't see the Hebrew properly in the source HTML.
Comment 6 Carsten Rinke 2013-04-27 17:35:56 UTC
Hi Lior,

I think I get your point here, and it surely is a valid point.

Unfortunately, I cannot pinpoint what the design intention has been so far. So I and up guessing, so please read this as my personal opinion.

My guess is, that the export function mainly should be used to make reports available to persons that do not use GnuCash an/or who should not have access to the original books.
In case of typos, these should be fixed in GnuCash, not outside GnuCash (and then re-export).
If different headings are needed for the same report (because of external requirements), then customized reports should be used for these reports, even if they only differ in the heading.

I hope I can somehow explain by this, why I do not see this a fault in the first place. But I agree that your point adds user friendliness to GnuCash, and certainly is an improvement. And this is, in my point of view, best indicated by severity ENH.
Comment 7 Geert Janssens 2013-12-08 15:54:01 UTC
The fact that the exported html is printing html escaped UTF-8 characters is not intended IMO, but rather a side effect of the way the html rendering works by default internally. I have not investigated this thoroughly.

At the same time I agree with Carsten that manipulating the exported html reports was not the design goal either, it was meant to be viewed in an external viewer. So in that context, what you describe is not a bug, but indeed an enhancement request.

I do understand it can be very useful to post-process the html report in various ways, to your request certainly makes sense.

Meanwhile there have been some changes in the locale handling of reports in the development series.

Can you test with gnucash 2.5.9 or any more recent nightly build and report back if these improve the generated html output for you ?

You can find the nightly builds here: http://code.gnucash.org/builds/win32/trunk/

And please note that this is still beta software, so be sure to back up your data before you install and run these test versions.
Comment 8 Geert Janssens 2014-09-23 15:55:09 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 9 John Ralls 2018-06-29 22:41:03 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=622210. Please update any external references or bookmarks.