none
Picking a font from a theme in WML RRS feed

  • Question

  • Hi there,

    I've read some of the previous discussions on the topic and proposed changes to the specification (I'm sadly forbidden from posting a link due to "unverified" account), all of which were useful. There's one area, however, which I would like to clarify.

    Let's say we have following set of fonts applied to a run...

    <w:rFonts 
      w:asciiTheme="minorHAnsi"
      w:eastAsiaTheme="minorHAnsi" 
      w:hAnsiTheme="minorHAnsi" 
      w:cstheme="minorBidi"/>

    And the following minor font collection in theme1.xml

    <a:minorFont>
      <a:latin typeface="Calibri"/>
      <a:ea typeface=""/>
      <a:cs typeface=""/>
      <a:font script="Jpan" typeface="MS 明朝"/>
      <a:font script="Hang" typeface="맑은 고딕"/>
      ...

    The sources I linked above clarify how for each unicode character we can figure out its "slot". For example, if the slot is "East Asia", then we'll be using "minorHAnsi" theme. As I understand, "minor" in the font theme indicates we should look into minor font collection (posted above). Now, here comes the question. What is "HAnsi" part in minorHAnsi used for?

    The spec (17.18.96) says that minorHAnsi means "minor theme font for the High ANSI range". However, there is no font for "High ANSI range" in a:minorFont. There're only fonts for latin, ea and cs, as the snippet above shows.

    My best guess is that I should ignore "HAnsi" part and simply determine font based on character's unicode script or w:lang element (by mapping those to one of a:font entries). Is that correct?

    I appreciate any help,

    Nikita

    [edit]

    Posting a link to the draft specification change I mentioned above. Have to do it "in disguise".

    onedrive.live.com/view.aspx/Public%20Documents/2009/DR-09-0040.docx?cid=c8ba0861dc5e4adc&sc=documents

    Thursday, June 5, 2014 9:17 AM

Answers

  • Hi Nikita,

    Annex L of the ISO-29500 specification contains some informative text about fonts that may help clarify the situation. Specifically, §L.1.9.7 states in part:

    Theme fonts are specified using the theme attribute variants in the rFonts element, rather than storing the actual font face name.
    
    For example, consider a run of text defined as follows:
    
        <w:r>
            <w:rPr>
                <w:rFonts w:asciiTheme="minorHAnsi" w:hAnsiTheme="minorHAnsi" />
            </w:rPr>
            …
        </w:r>
    
    The rFonts element's attribute values of asciiTheme and hAnsiTheme both store a reference to a theme font stored in the document's theme part (i.e., there is no font with the primary name minorHAnsi).
    
    Once this information has been established, it is combined with the theme language data stored in the document's settings to resolve the appropriate theme fonts from the theme part.

    This refers back to the normative specification for the document settings in 17.15. Specifically, §17.15.1.88 defines themeFontLang. I won’t quote the whole thing here, but the key element described here is how the mapping is accomplished:

    • For minorAscii/minorHAnsi, locate the font element in the minorFont element (§20.1.4.1.25) in the theme part for the language specified by the val attribute

    This brings us back to the theme, where the standard rules for selecting the typeface apply. For a document that has a themeFontLang value of ‘en-US’ and a character that is not from an East Asian or complex script, the latin typeface will be selected.

    In effect, this is basically the behavior that you surmised. You don’t do anything as a result of the ‘HAnsi’ part of the theme name aside from use the document’s language to resolve the font selection.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Monday, June 30, 2014 5:04 PM

All replies

  • Hi Nikita, thank you for your question. A member of the protocol documentation team will respond to you soon.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Thursday, June 5, 2014 2:05 PM
    Moderator
  • Hi Nikita,

    Annex L of the ISO-29500 specification contains some informative text about fonts that may help clarify the situation. Specifically, §L.1.9.7 states in part:

    Theme fonts are specified using the theme attribute variants in the rFonts element, rather than storing the actual font face name.
    
    For example, consider a run of text defined as follows:
    
        <w:r>
            <w:rPr>
                <w:rFonts w:asciiTheme="minorHAnsi" w:hAnsiTheme="minorHAnsi" />
            </w:rPr>
            …
        </w:r>
    
    The rFonts element's attribute values of asciiTheme and hAnsiTheme both store a reference to a theme font stored in the document's theme part (i.e., there is no font with the primary name minorHAnsi).
    
    Once this information has been established, it is combined with the theme language data stored in the document's settings to resolve the appropriate theme fonts from the theme part.

    This refers back to the normative specification for the document settings in 17.15. Specifically, §17.15.1.88 defines themeFontLang. I won’t quote the whole thing here, but the key element described here is how the mapping is accomplished:

    • For minorAscii/minorHAnsi, locate the font element in the minorFont element (§20.1.4.1.25) in the theme part for the language specified by the val attribute

    This brings us back to the theme, where the standard rules for selecting the typeface apply. For a document that has a themeFontLang value of ‘en-US’ and a character that is not from an East Asian or complex script, the latin typeface will be selected.

    In effect, this is basically the behavior that you surmised. You don’t do anything as a result of the ‘HAnsi’ part of the theme name aside from use the document’s language to resolve the font selection.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Monday, June 30, 2014 5:04 PM