Loading ...
Sorry, an error occurred while loading the content.

Re: [dita-users] How to tell the Open Toolkit to leave my fonts alone!

Expand Messages
  • Craig Sandvik
    The font post-processing can be useful even if you don t build localized content. Any content may use odd Unicode symbols that are not supported by your
    Message 1 of 16 , Sep 1, 2011
    • 0 Attachment
      The font post-processing can be useful even if you don't build localized content. Any
      content may use odd Unicode symbols that are not supported by your default fonts.
      The font post-processing allows you to trap these so they render in another font that
      has the right glyphs.

      E.g. last week we had to do this locally when someone used the Unicode number-in-circle
      characters.

      I haven't looked at the internals of the font substitution XSL in a while. If it's silently
      falling back to Helvetica, I would call that a bug. It should be logging a warning at
      least.

      I'll add these points to the DITA-OT tracker item.

      - craig


      From: Eliot Kimber <ekimber@...>
      To: "dita-users@yahoogroups.com" <dita-users@yahoogroups.com>
      Cc: "paul@..." <paul@...>
      Sent: Wednesday, August 31, 2011 2:40 PM
      Subject: Re: [dita-users] How to tell the Open Toolkit to leave my fonts alone!

       
      I'll take a look at the feature request and see if it's something I can fix
      and contribute, since I'm all up in the PDF innards of late.

      Cheers,

      E.

      On 8/31/11 4:36 PM, "Don Day" <donday@...> wrote:

      >
      >
      >
      >
      >
      > Regarding:
      >
      >
      >>
      >> I was playing with this some time ago and boy was it a pain.
      >>
      >
      >
      >>
      >> This seems like rather nasty Simon Says behavior. Would it be sensible to
      >>
      >
      >
      >>
      >> IMHO it seems like this is very 'rude' behavior on the part of the Open
      >> Toolkit.
      >>
      >
      > I am also a user and have the same problems. But I just want to point out
      > that the FO plugin was contributed by a vendor in the globalization business
      > who must have had reasons for assuming this default behavior. Whatever reason
      > for that behavior, it should not reflect on the integrity and reliability of
      > the broader DITA Open Toolkit, which I know is extensively tested by Robert
      > Anderson and his understaffed volunteer team even for each minor release.
      > Unlike the weather in Texas, this particular behavior (of font unfriendliness,
      > not Robert's care) can be changed--and since I could not find any similar
      > reported issue logged yet, I've put in a feature enhancement request for PDF2:
      > runtime switch for localization post-processing
      > <https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&atid
      > =725077>
      > (https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&atid
      > =725077) . If you can contribute some patch code for the issue, that would
      > raise its candidacy for testing and adding to one of the next updates. Small
      > mollification for the pains already endured, but I hope it helps.
      >
      >

      --
      Eliot Kimber
      Senior Solutions Architect
      "Bringing Strategy, Content, and Technology Together"
      Main: 512.554.9368
      www.reallysi.com
      www.rsuitecms.com



    • Eliot Kimber
      It seems like it should not modify the font family value when there is no mapping, but I also don t know all the reasons for what it does today. The original
      Message 2 of 16 , Sep 1, 2011
      • 0 Attachment
        It seems like it should not modify the font family value when there is no
        mapping, but I also don't know all the reasons for what it does today.

        The original Idiom approach seems to reflect an older time when FO engine's
        font handling, especially FOP's, was very weak and needed help. But I don't
        think that's the case any more. Unless I've misread the documentation, even
        FOP 1.0 supports font-character-mapping, meaning it should be able to find
        the right font for a character given appropriate configuration of the fonts
        in the FOP font mapping and correct specification of the font family list in
        the FO source.

        Cheers,

        E.

        On 9/1/11 9:46 AM, "Craig Sandvik" <distracticon@...> wrote:

        > The font post-processing can be useful even if you don't build localized
        > content. Any
        > content may use odd Unicode symbols that are not supported by your default
        > fonts.
        > The font post-processing allows you to trap these so they render in another
        > font that
        > has the right glyphs.
        >
        > E.g. last week we had to do this locally when someone used the Unicode
        > number-in-circle
        > characters.
        >
        > I haven't looked at the internals of the font substitution XSL in a while. If
        > it's silently
        > falling back to Helvetica, I would call that a bug. It should be logging a
        > warning at
        > least.
        >
        > I'll add these points to the DITA-OT tracker item.
        >
        > - craig
        >
        >
        > From: Eliot Kimber <ekimber@...>
        > To: "dita-users@yahoogroups.com" <dita-users@yahoogroups.com>
        > Cc: "paul@..." <paul@...>
        > Sent: Wednesday, August 31, 2011 2:40 PM
        > Subject: Re: [dita-users] How to tell the Open Toolkit to leave my fonts
        > alone!
        >
        >
        >
        > I'll take a look at the feature request and see if it's something I can fix
        > and contribute, since I'm all up in the PDF innards of late.
        >
        > Cheers,
        >
        > E.
        >
        > On 8/31/11 4:36 PM, "Don Day" <donday@... <mailto:donday%40bga.com> >
        > wrote:
        >
        >>
        >>
        >>
        >>
        >>
        >> Regarding:
        >>
        >>
        >>>
        >>> I was playing with this some time ago and boy was it a pain.
        >>>
        >>
        >>
        >>>
        >>> This seems like rather nasty Simon Says behavior. Would it be sensible to
        >>>
        >>
        >>
        >>>
        >>> IMHO it seems like this is very 'rude' behavior on the part of the Open
        >>> Toolkit.
        >>>
        >>
        >> I am also a user and have the same problems. But I just want to point out
        >> that the FO plugin was contributed by a vendor in the globalization business
        >> who must have had reasons for assuming this default behavior. Whatever reason
        >> for that behavior, it should not reflect on the integrity and reliability of
        >> the broader DITA Open Toolkit, which I know is extensively tested by Robert
        >> Anderson and his understaffed volunteer team even for each minor release.
        >> Unlike the weather in Texas, this particular behavior (of font
        >> unfriendliness,
        >> not Robert's care) can be changed--and since I could not find any similar
        >> reported issue logged yet, I've put in a feature enhancement request for
        >> PDF2:
        >> runtime switch for localization post-processing
        >>
        <https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&ati>>
        d
        >> =725077>
        >>
        (https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&ati>>
        d
        >> =725077) . If you can contribute some patch code for the issue, that would
        >> raise its candidacy for testing and adding to one of the next updates. Small
        >> mollification for the pains already endured, but I hope it helps.
        >>
        >>

        --
        Eliot Kimber
        Senior Solutions Architect
        "Bringing Strategy, Content, and Technology Together"
        Main: 512.554.9368
        www.reallysi.com
        www.rsuitecms.com
      • Craig Sandvik
        In our case, we noticed an error from Antenna House, No glyph for XXX in font times (or some such, don t remember the exact message). The most expedient fix
        Message 3 of 16 , Sep 1, 2011
        • 0 Attachment
          In our case, we noticed an error from Antenna House, "No glyph for XXX in font
          times" (or some such, don't remember the exact message). The most expedient fix was
          to modify the font mappings applied by the FO postprocessing.

          I know Antenna House does do some intelligent font substitution, but it did not
          work in this case.

          Possibly the mapping can be controlled directly in Antenna House configuration;
          I admit some ignorance in this area.

          - craig


          From: Eliot Kimber <ekimber@...>
          To: "dita-users@yahoogroups.com" <dita-users@yahoogroups.com>
          Sent: Thursday, September 1, 2011 7:53 AM
          Subject: Re: [dita-users] How to tell the Open Toolkit to leave my fonts alone!

           
          It seems like it should not modify the font family value when there is no
          mapping, but I also don't know all the reasons for what it does today.

          The original Idiom approach seems to reflect an older time when FO engine's
          font handling, especially FOP's, was very weak and needed help. But I don't
          think that's the case any more. Unless I've misread the documentation, even
          FOP 1.0 supports font-character-mapping, meaning it should be able to find
          the right font for a character given appropriate configuration of the fonts
          in the FOP font mapping and correct specification of the font family list in
          the FO source.

          Cheers,

          E.

          On 9/1/11 9:46 AM, "Craig Sandvik" <distracticon@...> wrote:

          > The font post-processing can be useful even if you don't build localized
          > content. Any
          > content may use odd Unicode symbols that are not supported by your default
          > fonts.
          > The font post-processing allows you to trap these so they render in another
          > font that
          > has the right glyphs.
          >
          > E.g. last week we had to do this locally when someone used the Unicode
          > number-in-circle
          > characters.
          >
          > I haven't looked at the internals of the font substitution XSL in a while. If
          > it's silently
          > falling back to Helvetica, I would call that a bug. It should be logging a
          > warning at
          > least.
          >
          > I'll add these points to the DITA-OT tracker item.
          >
          > - craig
          >
          >
          > From: Eliot Kimber <ekimber@...>
          > To: "dita-users@yahoogroups.com" <dita-users@yahoogroups.com>
          > Cc: "paul@..." <paul@...>
          > Sent: Wednesday, August 31, 2011 2:40 PM
          > Subject: Re: [dita-users] How to tell the Open Toolkit to leave my fonts
          > alone!
          >
          >
          >
          > I'll take a look at the feature request and see if it's something I can fix
          > and contribute, since I'm all up in the PDF innards of late.
          >
          > Cheers,
          >
          > E.
          >
          > On 8/31/11 4:36 PM, "Don Day" <donday@... <mailto:donday%40bga.com> >
          > wrote:
          >
          >>
          >>
          >>
          >>
          >>
          >> Regarding:
          >>
          >>
          >>>
          >>> I was playing with this some time ago and boy was it a pain.
          >>>
          >>
          >>
          >>>
          >>> This seems like rather nasty Simon Says behavior. Would it be sensible to
          >>>
          >>
          >>
          >>>
          >>> IMHO it seems like this is very 'rude' behavior on the part of the Open
          >>> Toolkit.
          >>>
          >>
          >> I am also a user and have the same problems. But I just want to point out
          >> that the FO plugin was contributed by a vendor in the globalization business
          >> who must have had reasons for assuming this default behavior. Whatever reason
          >> for that behavior, it should not reflect on the integrity and reliability of
          >> the broader DITA Open Toolkit, which I know is extensively tested by Robert
          >> Anderson and his understaffed volunteer team even for each minor release.
          >> Unlike the weather in Texas, this particular behavior (of font
          >> unfriendliness,
          >> not Robert's care) can be changed--and since I could not find any similar
          >> reported issue logged yet, I've put in a feature enhancement request for
          >> PDF2:
          >> runtime switch for localization post-processing
          >>
          <https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&ati>>
          d
          >> =725077>
          >>
          (https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&ati>>
          d
          >> =725077) . If you can contribute some patch code for the issue, that would
          >> raise its candidacy for testing and adding to one of the next updates. Small
          >> mollification for the pains already endured, but I hope it helps.
          >>
          >>

          --
          Eliot Kimber
          Senior Solutions Architect
          "Bringing Strategy, Content, and Technology Together"
          Main: 512.554.9368
          www.reallysi.com
          www.rsuitecms.com



        • juliov27612
          Somewhat related to this is a problem I encountered recently. While this is strictly the fault of the writers who coded the content, the result was a failure
          Message 4 of 16 , Sep 1, 2011
          • 0 Attachment
            Somewhat related to this is a problem I encountered recently. While this is strictly the fault of the writers who coded the content, the result was a failure to produce PDF. The copyright symbol and trademark symbols resulted in the physical font family being nullified when the glyph wasn't in the font family we were using. The result was that FOP exploded and the only way I could determine the problem was to look at the produced FO to find the failing characters.

            The moral of the story. Make sure your writers are using the <copyright> and <tm> elements when they want to mark that content in a document.

            'Nuff said.

            Julio J. Vazquez
            SDI Global Solutions

            --- In dita-users@yahoogroups.com, Craig Sandvik <distracticon@...> wrote:
            >
            > In our case, we noticed an error from Antenna House, "No glyph for XXX in font
            >
            > times"(or some such, don't remember the exact message). The most expedient fix was
            > to modify the font mappings applied by the FO postprocessing.
            >
            > I know Antenna House does do some intelligent font substitution, but it did not
            > work in this case.
            >
            > Possibly the mapping can be controlled directly in Antenna House configuration;
            > I admit some ignorance in this area.
            >
            >
            > - craig
            >
            >
            >
            > ________________________________
            > From: Eliot Kimber <ekimber@...>
            > To: "dita-users@yahoogroups.com" <dita-users@yahoogroups.com>
            > Sent: Thursday, September 1, 2011 7:53 AM
            > Subject: Re: [dita-users] How to tell the Open Toolkit to leave my fonts alone!
            >
            >
            >  
            > It seems like it should not modify the font family value when there is no
            > mapping, but I also don't know all the reasons for what it does today.
            >
            > The original Idiom approach seems to reflect an older time when FO engine's
            > font handling, especially FOP's, was very weak and needed help. But I don't
            > think that's the case any more. Unless I've misread the documentation, even
            > FOP 1.0 supports font-character-mapping, meaning it should be able to find
            > the right font for a character given appropriate configuration of the fonts
            > in the FOP font mapping and correct specification of the font family list in
            > the FO source.
            >
            > Cheers,
            >
            > E.
            >
            > On 9/1/11 9:46 AM, "Craig Sandvik" <distracticon@...> wrote:
            >
            > > The font post-processing can be useful even if you don't build localized
            > > content. Any
            > > content may use odd Unicode symbols that are not supported by your default
            > > fonts.
            > > The font post-processing allows you to trap these so they render in another
            > > font that
            > > has the right glyphs.
            > >
            > > E.g. last week we had to do this locally when someone used the Unicode
            > > number-in-circle
            > > characters.
            > >
            > > I haven't looked at the internals of the font substitution XSL in a while. If
            > > it's silently
            > > falling back to Helvetica, I would call that a bug. It should be logging a
            > > warning at
            > > least.
            > >
            > > I'll add these points to the DITA-OT tracker item.
            > >
            > > - craig
            > >
            > >
            > > From: Eliot Kimber <ekimber@...>
            > > To: "dita-users@yahoogroups.com" <dita-users@yahoogroups.com>
            > > Cc: "paul@..." <paul@...>
            > > Sent: Wednesday, August 31, 2011 2:40 PM
            > > Subject: Re: [dita-users] How to tell the Open Toolkit to leave my fonts
            > > alone!
            > >
            > >
            > >
            > > I'll take a look at the feature request and see if it's something I can fix
            > > and contribute, since I'm all up in the PDF innards of late.
            > >
            > > Cheers,
            > >
            > > E.
            > >
            > > On 8/31/11 4:36 PM, "Don Day" <donday@... <mailto:donday%40bga.com> >
            > > wrote:
            > >
            > >>
            > >>
            > >>
            > >>
            > >>
            > >> Regarding:
            > >>
            > >>
            > >>>
            > >>> I was playing with this some time ago and boy was it a pain.
            > >>>
            > >>
            > >>
            > >>>
            > >>> This seems like rather nasty Simon Says behavior. Would it be sensible to
            > >>>
            > >>
            > >>
            > >>>
            > >>> IMHO it seems like this is very 'rude' behavior on the part of the Open
            > >>> Toolkit.
            > >>>
            > >>
            > >> I am also a user and have the same problems. But I just want to point out
            > >> that the FO plugin was contributed by a vendor in the globalization business
            > >> who must have had reasons for assuming this default behavior. Whatever reason
            > >> for that behavior, it should not reflect on the integrity and reliability of
            > >> the broader DITA Open Toolkit, which I know is extensively tested by Robert
            > >> Anderson and his understaffed volunteer team even for each minor release.
            > >> Unlike the weather in Texas, this particular behavior (of font
            > >> unfriendliness,
            > >> not Robert's care) can be changed--and since I could not find any similar
            > >> reported issue logged yet, I've put in a feature enhancement request for
            > >> PDF2:
            > >> runtime switch for localization post-processing
            > >>
            > <https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&ati>>
            > d
            > >> =725077>
            > >>
            > (https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&ati>>
            > d
            > >> =725077) . If you can contribute some patch code for the issue, that would
            > >> raise its candidacy for testing and adding to one of the next updates. Small
            > >> mollification for the pains already endured, but I hope it helps.
            > >>
            > >>
            >
            > --
            > Eliot Kimber
            > Senior Solutions Architect
            > "Bringing Strategy, Content, and Technology Together"
            > Main: 512.554.9368
            > www.reallysi.com
            > www.rsuitecms.com
            >
          • Don Day
            While I agree with the practical sentiment of using markup where practicable, these are Unicode characters that are intended to be used in character form by
            Message 5 of 16 , Sep 1, 2011
            • 0 Attachment
              While I agree with the practical sentiment of using markup where
              practicable, these are Unicode characters that are intended to be used
              in character form by world-writing-system-aware systems. We can't
              restrict all incoming content to what amounts to guideline-based
              enforcement. So some form of font-mapping is certainly reasonable to
              catch these occasional mismatches between well-intended data and
              not-quite-accommodating production systems. But I also dig Craig's
              suggestion to port vendor-specific behaviors into personality modules as
              much as possible.

              The difficulty might be ensuring that any new design still works
              consistently for Asian and Eastern fonts, and that it might facilitate
              the production of PDFs with embedded fonts (which seems to be a black art).

              --
              Don Day
              Learning by Wrote
              Co-Chair, OASIS DITA Technical Committee



              On 9/1/2011 11:50 AM, juliov27612 wrote:
              > Somewhat related to this is a problem I encountered recently. While this is strictly the fault of the writers who coded the content, the result was a failure to produce PDF. The copyright symbol and trademark symbols resulted in the physical font family being nullified when the glyph wasn't in the font family we were using. The result was that FOP exploded and the only way I could determine the problem was to look at the produced FO to find the failing characters.
              >
              > The moral of the story. Make sure your writers are using the<copyright> and<tm> elements when they want to mark that content in a document.
              >
              > 'Nuff said.
              >
              > Julio J. Vazquez
              > SDI Global Solutions
              >
              > --- In dita-users@yahoogroups.com, Craig Sandvik<distracticon@...> wrote:
              >> In our case, we noticed an error from Antenna House, "No glyph for XXX in font
              >>
              >> times"(or some such, don't remember the exact message). The most expedient fix was
              >> to modify the font mappings applied by the FO postprocessing.
              >>
              >> I know Antenna House does do some intelligent font substitution, but it did not
              >> work in this case.
              >>
              >> Possibly the mapping can be controlled directly in Antenna House configuration;
              >> I admit some ignorance in this area.
              >>
              >>
              >> - craig
              >>
              >>
              >>
              >> ________________________________
              >> From: Eliot Kimber<ekimber@...>
              >> To: "dita-users@yahoogroups.com"<dita-users@yahoogroups.com>
              >> Sent: Thursday, September 1, 2011 7:53 AM
              >> Subject: Re: [dita-users] How to tell the Open Toolkit to leave my fonts alone!
              >>
              >>
              >> Â
              >> It seems like it should not modify the font family value when there is no
              >> mapping, but I also don't know all the reasons for what it does today.
              >>
              >> The original Idiom approach seems to reflect an older time when FO engine's
              >> font handling, especially FOP's, was very weak and needed help. But I don't
              >> think that's the case any more. Unless I've misread the documentation, even
              >> FOP 1.0 supports font-character-mapping, meaning it should be able to find
              >> the right font for a character given appropriate configuration of the fonts
              >> in the FOP font mapping and correct specification of the font family list in
              >> the FO source.
              >>
              >> Cheers,
              >>
              >> E.
              >>
              >> On 9/1/11 9:46 AM, "Craig Sandvik"<distracticon@...> wrote:
              >>
              >>> The font post-processing can be useful even if you don't build localized
              >>> content. Any
              >>> content may use odd Unicode symbols that are not supported by your default
              >>> fonts.
              >>> The font post-processing allows you to trap these so they render in another
              >>> font that
              >>> has the right glyphs.
              >>>
              >>> E.g. last week we had to do this locally when someone used the Unicode
              >>> number-in-circle
              >>> characters.
              >>>
              >>> I haven't looked at the internals of the font substitution XSL in a while. If
              >>> it's silently
              >>> falling back to Helvetica, I would call that a bug. It should be logging a
              >>> warning at
              >>> least.
              >>>
              >>> I'll add these points to the DITA-OT tracker item.
              >>>
              >>> - craig
              >>>
              >>>
              >>> From: Eliot Kimber<ekimber@...>
              >>> To: "dita-users@yahoogroups.com"<dita-users@yahoogroups.com>
              >>> Cc: "paul@..."<paul@...>
              >>> Sent: Wednesday, August 31, 2011 2:40 PM
              >>> Subject: Re: [dita-users] How to tell the Open Toolkit to leave my fonts
              >>> alone!
              >>>
              >>>
              >>>
              >>> I'll take a look at the feature request and see if it's something I can fix
              >>> and contribute, since I'm all up in the PDF innards of late.
              >>>
              >>> Cheers,
              >>>
              >>> E.
              >>>
              >>> On 8/31/11 4:36 PM, "Don Day"<donday@...<mailto:donday%40bga.com> >
              >>> wrote:
              >>>
              >>>>
              >>>>
              >>>>
              >>>>
              >>>> Regarding:
              >>>>
              >>>>
              >>>>> I was playing with this some time ago and boy was it a pain.
              >>>>>
              >>>>
              >>>>> This seems like rather nasty Simon Says behavior. Would it be sensible to
              >>>>>
              >>>>
              >>>>> IMHO it seems like this is very 'rude' behavior on the part of the Open
              >>>>> Toolkit.
              >>>>>
              >>>> I am also a user and have the same problems. But I just want to point out
              >>>> that the FO plugin was contributed by a vendor in the globalization business
              >>>> who must have had reasons for assuming this default behavior. Whatever reason
              >>>> for that behavior, it should not reflect on the integrity and reliability of
              >>>> the broader DITA Open Toolkit, which I know is extensively tested by Robert
              >>>> Anderson and his understaffed volunteer team even for each minor release.
              >>>> Unlike the weather in Texas, this particular behavior (of font
              >>>> unfriendliness,
              >>>> not Robert's care) can be changed--and since I could not find any similar
              >>>> reported issue logged yet, I've put in a feature enhancement request for
              >>>> PDF2:
              >>>> runtime switch for localization post-processing
              >>>>
              >> <https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&ati>>
              >> d
              >>>> =725077>
              >>>>
              >> (https://sourceforge.net/tracker/?func=detail&aid=3401849&group_id=132728&ati>>
              >> d
              >>>> =725077) . If you can contribute some patch code for the issue, that would
              >>>> raise its candidacy for testing and adding to one of the next updates. Small
              >>>> mollification for the pains already endured, but I hope it helps.
              >>>>
              >>>>
              >> --
              >> Eliot Kimber
              >> Senior Solutions Architect
              >> "Bringing Strategy, Content, and Technology Together"
              >> Main: 512.554.9368
              >> www.reallysi.com
              >> www.rsuitecms.com
              >>
            • rob.cavicchio@emc.com
              ... Do you mean the character-by-character font selection strategy? FOP 1.0 still does not intelligently substitute fonts. If the font that you specify first
              Message 6 of 16 , Sep 1, 2011
              • 0 Attachment
                "Eliot Kimber" ekimber@... drmacro wrote:

                > The original Idiom approach seems to reflect an older time when FO
                > engine's
                > font handling, especially FOP's, was very weak and needed help. But I
                > don't
                > think that's the case any more. Unless I've misread the documentation,
                > even
                > FOP 1.0 supports font-character-mapping, meaning it should be able to
                > find
                > the right font for a character given appropriate configuration of the
                > fonts
                > in the FOP font mapping and correct specification of the font family
                > list in
                > the FO source.


                Do you mean the "character-by-character" font selection strategy?

                FOP 1.0 still does not intelligently substitute fonts. If the font that you specify first does not contain the character, you get an error and a placeholder glyph (#) in the output. You can specify backup fonts and a character-by-character selection strategy, and FOP will no longer produce any errors for the valid FO markup, but it does not actually implement the expected behavior.


                *************************
                Rob Cavicchio
                Principal Technical Writer & Information Architect
                Information Intelligence Group
                EMC Corporation
                3721 Valley Centre Drive, Ste 200
                San Diego, CA 92130

                P: (858) 320-1208
                F: (858) 320-1010
                E: rob.cavicchio@...

                The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.
              • Eliot Kimber
                Yes, I meant character-by-character . Bummer about FOP, but not exactly a surprise. So the FO-instance post-process is still required if you re using FOP.
                Message 7 of 16 , Sep 1, 2011
                • 0 Attachment
                  Yes, I meant "character-by-character". Bummer about FOP, but not exactly a
                  surprise.

                  So the FO-instance post-process is still required if you're using FOP. Hmmm.

                  But it certainly shouldn't be required if you're using XEP or XSL Formatter,
                  as long as you provide an appropriate set of fonts or otherwise configure
                  font fallback at the FO engine level, as far as I know.

                  Cheers,

                  E.

                  On 9/1/11 3:14 PM, "rob.cavicchio@..." <rob.cavicchio@...> wrote:

                  > "Eliot Kimber" ekimber@... <mailto:ekimber%40reallysi.com> drmacro
                  > wrote:
                  >
                  >> The original Idiom approach seems to reflect an older time when FO
                  >> engine's
                  >> font handling, especially FOP's, was very weak and needed help. But I
                  >> don't
                  >> think that's the case any more. Unless I've misread the documentation,
                  >> even
                  >> FOP 1.0 supports font-character-mapping, meaning it should be able to
                  >> find
                  >> the right font for a character given appropriate configuration of the
                  >> fonts
                  >> in the FOP font mapping and correct specification of the font family
                  >> list in
                  >> the FO source.
                  >
                  >
                  > Do you mean the "character-by-character" font selection strategy?
                  >
                  > FOP 1.0 still does not intelligently substitute fonts. If the font that you
                  > specify first does not contain the character, you get an error and a
                  > placeholder glyph (#) in the output. You can specify backup fonts and a
                  > character-by-character selection strategy, and FOP will no longer produce any
                  > errors for the valid FO markup, but it does not actually implement the
                  > expected behavior.
                  >
                  >
                  > *************************
                  > Rob Cavicchio
                  > Principal Technical Writer & Information Architect
                  > Information Intelligence Group
                  > EMC Corporation
                  > 3721 Valley Centre Drive, Ste 200
                  > San Diego, CA 92130
                  >
                  > P: (858) 320-1208
                  > F: (858) 320-1010
                  > E: rob.cavicchio@... <mailto:rob.cavicchio%40emc.com>
                  >
                  > The opinions expressed here are my personal opinions. Content published here
                  > is not read or approved in advance by EMC and does not necessarily reflect the
                  > views and opinions of EMC.
                  >
                  >
                  >
                  >
                  >

                  --
                  Eliot Kimber
                  Senior Solutions Architect
                  "Bringing Strategy, Content, and Technology Together"
                  Main: 512.554.9368
                  www.reallysi.com
                  www.rsuitecms.com
                • juliov27612
                  And there s the rub. I don t know if the OT can detect whether a font substitution is needed at a particular character point, but nullifying the physical font
                  Message 8 of 16 , Sep 2, 2011
                  • 0 Attachment
                    And there's the rub. I don't know if the OT can detect whether a font substitution is needed at a particular character point, but nullifying the physical font is definitely not the answer when it encounters that problem. I did submit an RFE for this because there should be a more graceful way of handling this sort of issue.

                    I still do want folks to do the right thing when that's available.

                    A different question is why there is no <copyrighttext> element that would allow encoding content of a copyright statement outside of the <bookmap> <prolog>? Even a <copyrighttext> specialization of <topicref> may be useful. It might even make sense to auto-generate the copyright symbol followed by a space as the first character of the rendering of the text. This would eliminate remembering the codepoints to generate that particular (and common) glyph and give you the ability to place the copyright statement wherever you want it.

                    What do you all think?

                    Julio J. Vazquez
                    SDI Global Solutions

                    --- In dita-users@yahoogroups.com, Eliot Kimber <ekimber@...> wrote:
                    >
                    > Yes, I meant "character-by-character". Bummer about FOP, but not exactly a
                    > surprise.
                    >
                    > So the FO-instance post-process is still required if you're using FOP. Hmmm.
                    >
                    > But it certainly shouldn't be required if you're using XEP or XSL Formatter,
                    > as long as you provide an appropriate set of fonts or otherwise configure
                    > font fallback at the FO engine level, as far as I know.
                    >
                    > Cheers,
                    >
                    > E.
                    >
                    > On 9/1/11 3:14 PM, "rob.cavicchio@..." <rob.cavicchio@...> wrote:
                    >
                    > > "Eliot Kimber" ekimber@... <mailto:ekimber%40reallysi.com> drmacro
                    > > wrote:
                    > >
                    > >> The original Idiom approach seems to reflect an older time when FO
                    > >> engine's
                    > >> font handling, especially FOP's, was very weak and needed help. But I
                    > >> don't
                    > >> think that's the case any more. Unless I've misread the documentation,
                    > >> even
                    > >> FOP 1.0 supports font-character-mapping, meaning it should be able to
                    > >> find
                    > >> the right font for a character given appropriate configuration of the
                    > >> fonts
                    > >> in the FOP font mapping and correct specification of the font family
                    > >> list in
                    > >> the FO source.
                    > >
                    > >
                    > > Do you mean the "character-by-character" font selection strategy?
                    > >
                    > > FOP 1.0 still does not intelligently substitute fonts. If the font that you
                    > > specify first does not contain the character, you get an error and a
                    > > placeholder glyph (#) in the output. You can specify backup fonts and a
                    > > character-by-character selection strategy, and FOP will no longer produce any
                    > > errors for the valid FO markup, but it does not actually implement the
                    > > expected behavior.
                    > >
                    > >
                    > > *************************
                    > > Rob Cavicchio
                    > > Principal Technical Writer & Information Architect
                    > > Information Intelligence Group
                    > > EMC Corporation
                    > > 3721 Valley Centre Drive, Ste 200
                    > > San Diego, CA 92130
                    > >
                    > > P: (858) 320-1208
                    > > F: (858) 320-1010
                    > > E: rob.cavicchio@... <mailto:rob.cavicchio%40emc.com>
                    > >
                    > > The opinions expressed here are my personal opinions. Content published here
                    > > is not read or approved in advance by EMC and does not necessarily reflect the
                    > > views and opinions of EMC.
                    > >
                    > >
                    > >
                    > >
                    > >
                    >
                    > --
                    > Eliot Kimber
                    > Senior Solutions Architect
                    > "Bringing Strategy, Content, and Technology Together"
                    > Main: 512.554.9368
                    > www.reallysi.com
                    > www.rsuitecms.com
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.