Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Trunk
    • Fix Version/s: Trunk
    • Component/s: framework
    • Labels:
      None

      Description

      current ofbiz(OOTB) reporting does not support multilingual users. When you use non-english locale you get '#" characters.
      additionally it is hard to track all changes in reports so here default font comes up.
      it would be great to add fop.xcon file to trunk with UNICODE font that could print any characters in any languages.

      I've made up two another solutions 1) is a property in general.properties that store default font
      2) to associate font-family name with locale as property (in property file) and use this font-family to print reports in user language properly.

      with second solution users can define what fonts they have and want to use

      1. widget.diff
        6 kB
        Oleg Andreyev

        Activity

        Hide
        David E. Jones added a comment -

        One of the big design goals of OFBiz is to support larger and more varied organizations. In other words, we need ways that things can support different languages, fonts, locales, etc for the same artifacts. So, #2 would be better than #1, and as a general solution some variation of #2 might be better.

        Show
        David E. Jones added a comment - One of the big design goals of OFBiz is to support larger and more varied organizations. In other words, we need ways that things can support different languages, fonts, locales, etc for the same artifacts. So, #2 would be better than #1, and as a general solution some variation of #2 might be better.
        Hide
        Oleg Andreyev added a comment -

        A few comments to this topic.

        I think we have to transfer tags page-width and page-height to configuration file as generally used paper formats differ in various countries. It would be better changing these parameters in one place. Of course this is applied to reports currently printed as Letter, or similar formats.

        Inasmuch as class ApacheFopFactory is using file fop.properties(at least envisage it), what about adding default font face to it instead of general.properties?

        I have attached patch with starting fop.xconf. To commiters. Please, apply it to trunk as starting point for further activity. This variant of the configuration file not impact current functionality.

        Show
        Oleg Andreyev added a comment - A few comments to this topic. I think we have to transfer tags page-width and page-height to configuration file as generally used paper formats differ in various countries. It would be better changing these parameters in one place. Of course this is applied to reports currently printed as Letter, or similar formats. Inasmuch as class ApacheFopFactory is using file fop.properties(at least envisage it), what about adding default font face to it instead of general.properties? I have attached patch with starting fop.xconf. To commiters. Please, apply it to trunk as starting point for further activity. This variant of the configuration file not impact current functionality.
        Hide
        Krzysztof Podejma added a comment -

        Additionally this issue should cover cases when reports are printed with different currency.
        Currency abbreviations I mean. So when report is in English but uses polish currency, this currency should be printed well.

        Show
        Krzysztof Podejma added a comment - Additionally this issue should cover cases when reports are printed with different currency. Currency abbreviations I mean. So when report is in English but uses polish currency, this currency should be printed well.
        Hide
        Jacopo Cappellato added a comment -

        Thaks to all: the fop.xconf file is in rev. 564545
        However the folder for the file is webapp/config and not in widget/config

        Show
        Jacopo Cappellato added a comment - Thaks to all: the fop.xconf file is in rev. 564545 However the folder for the file is webapp/config and not in widget/config
        Hide
        Oleg Andreyev added a comment -

        Thanks Jacopo,

        But please reopen this issue. Config file is first step only. Now it is on-site and we can go ahead.

        Show
        Oleg Andreyev added a comment - Thanks Jacopo, But please reopen this issue. Config file is first step only. Now it is on-site and we can go ahead.
        Hide
        Jacques Le Roux added a comment -

        Should we reopen of create a new issue ?

        Show
        Jacques Le Roux added a comment - Should we reopen of create a new issue ?
        Hide
        Jacopo Cappellato added a comment -

        Oleg,

        I'd say to create a new Jira issue (and maybe sub-tasks for it) to keep things cleaner.
        It's great to know that you are interested in improving the current features: exactly, what are the next steps that you are planning to work?

        In my opinion, in order to add flexibility for other properties (such as page-width and page-height ), we should set them in the "actions" section of the screen decorators for xsl-fo based reports; please, have a look at rev 564554 ( http://svn.apache.org/viewvc?view=rev&revision=564554 ) and how I set there the font-family property: we can do the same for other properies as pageWidth and pageHeight.

        Show
        Jacopo Cappellato added a comment - Oleg, I'd say to create a new Jira issue (and maybe sub-tasks for it) to keep things cleaner. It's great to know that you are interested in improving the current features: exactly, what are the next steps that you are planning to work? In my opinion, in order to add flexibility for other properties (such as page-width and page-height ), we should set them in the "actions" section of the screen decorators for xsl-fo based reports; please, have a look at rev 564554 ( http://svn.apache.org/viewvc?view=rev&revision=564554 ) and how I set there the font-family property: we can do the same for other properies as pageWidth and pageHeight.
        Hide
        Oleg Andreyev added a comment -

        Jacopo, Jacquals,

        Really it's doesn't metter reopen this issue or make new one. On other hand Krzysztof is creator of it.

        Jacopo,
        I post my previous comment before have a chance to see your next patch. In general I dream about Ofbiz that can print correctly OOTB.
        Last time ago I spend a few days to make it working and now this problem isn't mine but new customer's and developer's.
        To archive this goal I plan add free truetype fonts and their metrics, make Arial as default font (now it's extremely easy, thanks Jacopo) and move page geometry settings from reports to config.

        I am not in accord with you about placing page geometry in decorator. We have two alternatives as to configure FOP - programmatically or via configuration file. I vote second one. This is more natural way. And I think this way don't mislead new customers.

        Show
        Oleg Andreyev added a comment - Jacopo, Jacquals, Really it's doesn't metter reopen this issue or make new one. On other hand Krzysztof is creator of it. Jacopo, I post my previous comment before have a chance to see your next patch. In general I dream about Ofbiz that can print correctly OOTB. Last time ago I spend a few days to make it working and now this problem isn't mine but new customer's and developer's. To archive this goal I plan add free truetype fonts and their metrics, make Arial as default font (now it's extremely easy, thanks Jacopo) and move page geometry settings from reports to config. I am not in accord with you about placing page geometry in decorator. We have two alternatives as to configure FOP - programmatically or via configuration file. I vote second one. This is more natural way. And I think this way don't mislead new customers.
        Hide
        Krzysztof Podejma added a comment -

        This issue is definitely not completed. I'll post my proposals when I have more time to prepare it.
        Maybe next week.

        Show
        Krzysztof Podejma added a comment - This issue is definitely not completed. I'll post my proposals when I have more time to prepare it. Maybe next week.
        Hide
        Jacques Le Roux added a comment -

        Reopened at Krzysztof's demand.

        BTW Oleg, my 1st name is not Jacquals (nice too though ;o) but Jacques (it's french)

        Show
        Jacques Le Roux added a comment - Reopened at Krzysztof's demand. BTW Oleg, my 1st name is not Jacquals (nice too though ;o) but Jacques (it's french)
        Hide
        Jacopo Cappellato added a comment -

        Oleg,

        I don't think that your plan (configuring fop out-of-the-box to use/embed an open source font able to render a wide range of character sets) is incompatible with mine (adding the ability to pass to the fo.ftl template variable to render non default font families, page geometries etc...).
        The two features can be used both:
        1) out of the box the default OFBiz reports should be able to work with as many character sets as possible
        2) now it's already possible to global change the default properties of all the reports in the fop.xconf file
        3) adding variable to the screen template action and fo.ftl template will allow to configure particular report in a non default way (for example based on user's settings/locale etc...); if the variables are not set in the screen (the default) then the standard properties from fop.xconf will be applied

        Show
        Jacopo Cappellato added a comment - Oleg, I don't think that your plan (configuring fop out-of-the-box to use/embed an open source font able to render a wide range of character sets) is incompatible with mine (adding the ability to pass to the fo.ftl template variable to render non default font families, page geometries etc...). The two features can be used both: 1) out of the box the default OFBiz reports should be able to work with as many character sets as possible 2) now it's already possible to global change the default properties of all the reports in the fop.xconf file 3) adding variable to the screen template action and fo.ftl template will allow to configure particular report in a non default way (for example based on user's settings/locale etc...); if the variables are not set in the screen (the default) then the standard properties from fop.xconf will be applied
        Hide
        Oleg Andreyev added a comment -

        Jacopo,

        > 3) adding variable to the screen template action and fo.ftl template will allow to configure particular report in a non default way (for example based on > user's settings/locale etc...); if the variables are not set in the screen (the default) then the standard properties from fop.xconf will be applied

        I think this is right way. And I am glad that you become interested in this problem.

        Show
        Oleg Andreyev added a comment - Jacopo, > 3) adding variable to the screen template action and fo.ftl template will allow to configure particular report in a non default way (for example based on > user's settings/locale etc...); if the variables are not set in the screen (the default) then the standard properties from fop.xconf will be applied I think this is right way. And I am glad that you become interested in this problem.
        Hide
        Christian Geisert added a comment -

        Yes, it should be easy to use non Latin-1 fonts for PDF/Printing.

        If we include a custom font (and the generated metrics) the only thing a user would have to do is change the font name in the config (as FOP isn't intelligent enough yet to use only the needed fonts)

        The DejaVu fonts (http://dejavu.sourceforge.net/ , see http://issues.apache.org/bugzilla/show_bug.cgi?id=40465 for details on license and format) seem to be ok and include Cyrillic, Greek, Arabic and a lot more but no Chinese/CJK fonts - the only issue might be the size of the font.

        Show
        Christian Geisert added a comment - Yes, it should be easy to use non Latin-1 fonts for PDF/Printing. If we include a custom font (and the generated metrics) the only thing a user would have to do is change the font name in the config (as FOP isn't intelligent enough yet to use only the needed fonts) The DejaVu fonts ( http://dejavu.sourceforge.net/ , see http://issues.apache.org/bugzilla/show_bug.cgi?id=40465 for details on license and format) seem to be ok and include Cyrillic, Greek, Arabic and a lot more but no Chinese/CJK fonts - the only issue might be the size of the font.
        Hide
        Oleg Andreyev added a comment -

        The size of the font isn't a problem. FOP embeds in document only used gryphs of TrueType font.

        Show
        Oleg Andreyev added a comment - The size of the font isn't a problem. FOP embeds in document only used gryphs of TrueType font.
        Hide
        Radoslav Kolev added a comment -

        Hello!

        Since this issue is still open, I think it is better to post my question here.

        I need to generate PDFs with non-latin characters. Since the additions of the fop.xconf and the DejaVu font collection everything needed is here. After some config tweaking if I edit the corresponding fo.ftl file and change it to use one of the DejaVu fonts it works fine.

        What I don't know how to do is set,lets say DejaVuSans, as the default font for all the generated PDFs. I can make a mass search/replace and add this to all fo.ftl files, but I hope someone can propose a more elegant and clean solution.

        May be some template that is inluded in all the fo.ftl files?

        Best regards,
        Radoslav Kolev

        Show
        Radoslav Kolev added a comment - Hello! Since this issue is still open, I think it is better to post my question here. I need to generate PDFs with non-latin characters. Since the additions of the fop.xconf and the DejaVu font collection everything needed is here. After some config tweaking if I edit the corresponding fo.ftl file and change it to use one of the DejaVu fonts it works fine. What I don't know how to do is set,lets say DejaVuSans, as the default font for all the generated PDFs. I can make a mass search/replace and add this to all fo.ftl files, but I hope someone can propose a more elegant and clean solution. May be some template that is inluded in all the fo.ftl files? Best regards, Radoslav Kolev
        Hide
        Krzysztof Podejma added a comment -

        You can set font-family in simple.fo.ftl ie. <fo:page-sequence master-reference="main-page" font-family="Arial">.
        In this example all blocks will use Arial font.

        Regards
        Krzysztof Podejma

        Show
        Krzysztof Podejma added a comment - You can set font-family in simple.fo.ftl ie. <fo:page-sequence master-reference="main-page" font-family="Arial">. In this example all blocks will use Arial font. Regards Krzysztof Podejma
        Hide
        Adrian Crum added a comment -

        Radoslav,

        Take a look at the files in framework/common/webcommon/includes/fo and the GlobalFoDecorator in CommonScreens.xml. They accept a parameter to control the default font.

        Show
        Adrian Crum added a comment - Radoslav, Take a look at the files in framework/common/webcommon/includes/fo and the GlobalFoDecorator in CommonScreens.xml. They accept a parameter to control the default font.
        Hide
        Radoslav Kolev added a comment -

        Hello Krzysztof,

        and thanks for the fast reply.

        Unfortunately, this doesn't fix the problem in all PDFs for me.

        For example if I generate an Invoice using

        https://localhost:8443/accounting/control/invoice.pdf?invoiceId=10000

        I will still get # instead of non-latin letters. If I add a font-family="DejaVuSans" attribute in the corresponding fo.ftl template (in this case 'applications/accounting/webapp/accounting/invoice/viewInvoice.fo.ftl') the characters display fine.

        It is a similar situation with a lot of other places where PDFs are generated. Adding the font-family attribute to the respective fo.ftl file fixes the issue.

        Only adding it to the simple.fo.ftl and reportTemplate.fo.ftl (as I read in the description of some other bug) does not fix all places where PDFs are generated in my test install. Do you have any idea is this expected behaviour or not?

        Regards,
        Rado

        Show
        Radoslav Kolev added a comment - Hello Krzysztof, and thanks for the fast reply. Unfortunately, this doesn't fix the problem in all PDFs for me. For example if I generate an Invoice using https://localhost:8443/accounting/control/invoice.pdf?invoiceId=10000 I will still get # instead of non-latin letters. If I add a font-family="DejaVuSans" attribute in the corresponding fo.ftl template (in this case 'applications/accounting/webapp/accounting/invoice/viewInvoice.fo.ftl') the characters display fine. It is a similar situation with a lot of other places where PDFs are generated. Adding the font-family attribute to the respective fo.ftl file fixes the issue. Only adding it to the simple.fo.ftl and reportTemplate.fo.ftl (as I read in the description of some other bug) does not fix all places where PDFs are generated in my test install. Do you have any idea is this expected behaviour or not? Regards, Rado
        Hide
        Radoslav Kolev added a comment -

        Adrian, I have already looked at these files.

        In CommonScreens.xml I have added this action

        <set field="defaultFontFamily" value="DejaVuSans"/>

        to the definitions of the FoReportDecorator and FoDecorator screens. There is no GlobalFoDecorator screen in my version of CommonScreens.xml (updated from svn yesterday).

        I suppose this should trigger the following conditional

        <#if defaultFontFamily?has_content>font-family="$

        {defaultFontFamily}

        "</#if>

        in the beggining of reportTemplate.fo.ftl and simple.fo.ftl.

        Even after these changes I still don't see properly the non-latin characters in PDFs. I tried replacing the conditionals in reportTemplate.fo.ftl and simple.fo.ftl with a hardcoded value of font-family="DejaVuSans" but still no much difference.

        Any ideas?

        Thanks,
        Rado

        Show
        Radoslav Kolev added a comment - Adrian, I have already looked at these files. In CommonScreens.xml I have added this action <set field="defaultFontFamily" value="DejaVuSans"/> to the definitions of the FoReportDecorator and FoDecorator screens. There is no GlobalFoDecorator screen in my version of CommonScreens.xml (updated from svn yesterday). I suppose this should trigger the following conditional <#if defaultFontFamily?has_content>font-family="$ {defaultFontFamily} "</#if> in the beggining of reportTemplate.fo.ftl and simple.fo.ftl. Even after these changes I still don't see properly the non-latin characters in PDFs. I tried replacing the conditionals in reportTemplate.fo.ftl and simple.fo.ftl with a hardcoded value of font-family="DejaVuSans" but still no much difference. Any ideas? Thanks, Rado
        Hide
        Jacques Le Roux added a comment -

        I close this issue since all is ok but the problem Radoslav reported. I propose to create a new issue for that if still needed.

        Show
        Jacques Le Roux added a comment - I close this issue since all is ok but the problem Radoslav reported. I propose to create a new issue for that if still needed.

          People

          • Assignee:
            Jacopo Cappellato
            Reporter:
            Krzysztof Podejma
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development