Created attachment 31845 [details]
A snapshot that illustrates unexpected behavior.

->tora: Could you please explain what you want to achieve exactly and in what
way GetDefaultFont does not work as expected ?

Sorry for less information. Let me describe what i wanted to say.

 The point of this issue:
   It would be a better way that a default fontname of individual application 
   such as Writer could be an actual, physical fontname obtained from a font file.
   Current, 2.0 final, implementation, however, chooses a hand-typed fontname 
   listed in the file VCL.xcu.


 Background:
   VCL.xcu holds texts separated by a semicolon, which represents fontnames.
   The texts, however, are messed up with the followings:
     - Identical to the fontname defined in the font file, i.e. physical name.
     - Similar to the physical name, but misspells can be found: capitalized, 
       fullwidthed, existence of spece letter, things like that.
     - Normalized, e.g. halfwidthed, lowercased, and space-eliminated.

 A default font name of individual application
   seems to be determined by the following steps:
     - An application asks the VCL layer to obtain a default fontname.
     - VCL layer gets a list of fontnames installed in the system, 
       and obtains a list of fontnames defineded in the file VCL.xcu, 
       and trys to match fontnames that are included in both lists,
       and return the fontname which is considered equal between the lists.

 Which fontname should be returned:
     - It would be better way that soffice chooses a physical font name 
       defined in the font file.

 What is going on:
     - The 2.0 final chooses a text of fontname listed in the file VCL.xcu 
       instead of the physical fontname. 
     - The chosen fontname sometime includes misspells from operating system's
       point of view because it is typed by hand in the file VCL.xcu.
     - The misspelled fontname, however, does not make a problem with the 
       rendering system of soffice. soffice can treat it as correct.

 What are the potential problems:
     - Consequently, a fontname shown in the fontname box of the tool bar 
       does not match a fontname listed in the list of context menu.
       This phenomenon is illustrated in the snapshot. No check mark is found.
     - Eventually, after the document is exported into external file format, 
       some application software can not recognize the misspelled fontname.

 What code could be improved:
   It might be difficult to find. A code of the method 
   OutputDevice::GetDefaultFont() looks to be written to return a fontname 
   found in a list of the available fontnames installed in the system. 
   The application, however, shows a fontname defined in the file VCL.xcu.

Actually the caller of GetDefaultFont decides whether he wants the whole list or
the first existing font.

I guess the applications currently get the whole list since it increases
portability of documents: if you include a whole list of fonts which are
similar, then you have a better chance of a good result when viewing/editing
that document on another machine that does not have the same set of fonts. If
one included only one font then one would get a rather undefined fallback on
systems that do not have that font.

But ultimately this would be something the applications have to decide/fix.

Thank you for taking care of this issue. i can agree with your guess.

Could you think of different behavior illustrated in the second snapshot?
  
  1. Making a fontname Thorndale wrong by adding burahburah resulted in 
     a choice of another available font Times New Roman.

     <value>Thorndale burahburah;Times New Roman;Bitstream Vera Serif;Times;...

  2. Removing font files of the candidate Times New Roman resulted in 
     a choice of another available font Bitstream Vera Serif.

  That results infer that soffice is capable to find an available, suitable 
  font according to the preferences defined in the file VCL.xcu.


It could be inefficient if every applications get a list of whole candidates
and confirm if each font in the list is available on the system by itself. 
There might be a common routine shared by the applications that determine a 
default font. The common routine, however, might be redundant because the VCL 
layer offers such functionality.

The following command on the directory in which the source code tree resides
shows many codes in the upper layer call GetDefaultFont() with a parameter 
DEFAULTFONT_FLAGS_ONLYONE.

  find . -name '*.cxx' | xargs gnugrep -A 3 GetDefaultFont

  Font aFont( OutputDevice::GetDefaultFont( DEFAULTFONT_SERIF, eLangType,
              DEFAULTFONT_FLAGS_ONLYONE, &rExampleWin ) );




Could you please consider this issue a little bit more serious? 

Interoperability with other existing application software is becoming more 
important for populating soffice. Clearly, wrong, hand-typed, misspelled font 
names can impede interoperability.

Created attachment 31952 [details]
The second snapshot that trys to illustrate soffice can choose properly an available font.

.

We already return the physical fontname when the static
OutputDevice::GetDefaultFont() method is called with a specific output device as
target. Only for method invocations where this output device target is not
provided the font name is taken from the configuration entry.

HDU->OS: please provide a pOutputDevice argument to get the best default font name

Target set to OOo 3.0

Target adjusted

target 3.x

Pointer to issue 84684, which updates the situation after the recent changes regarding fontconfig 
integration.

Reset assigne to the default "issues@openoffice.apache.org".