Issue 58535 - OutputDevice::GetDefaultFont() seems to return a font name listed in VCL.xcu
Summary: OutputDevice::GetDefaultFont() seems to return a font name listed in VCL.xcu
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.0
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.x
Assignee: AOO issues mailing list
QA Contact:
Depends on: 84684
  Show dependency tree
Reported: 2005-11-28 06:55 UTC by tora3
Modified: 2017-05-20 11:31 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

A snapshot that illustrates unexpected behavior. (279.24 KB, image/png)
2005-11-28 06:56 UTC, tora3
no flags Details
The second snapshot that trys to illustrate soffice can choose properly an available font. (293.91 KB, image/png)
2005-12-01 08:17 UTC, tora3
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description tora3 2005-11-28 06:55:13 UTC
OutputDevice::GetDefaultFont() in vcl/source/gdi/outdev3.cxx seems to 
attempt to return a physical font name. 

The fact, however, illustrated in a snapshot attached, shows different behavior.

As discussed in October, GetDefaultFont() can provide a physical font name.
Comment 1 tora3 2005-11-28 06:56:55 UTC
Created attachment 31845 [details]
A snapshot that illustrates unexpected behavior.
Comment 2 stephan_schaefer 2005-11-29 15:35:48 UTC
->tora: Could you please explain what you want to achieve exactly and in what
way GetDefaultFont does not work as expected ?

Comment 3 tora3 2005-11-30 07:54:34 UTC
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.

   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.
Comment 4 philipp.lohmann 2005-11-30 09:56:47 UTC
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.
Comment 5 tora3 2005-12-01 08:12:04 UTC
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 

  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.
Comment 6 tora3 2005-12-01 08:17:08 UTC
Created attachment 31952 [details]
The second snapshot that trys to illustrate soffice can choose properly an available font.
Comment 7 2005-12-01 10:13:43 UTC
Comment 8 2005-12-16 16:18:05 UTC
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
Comment 9 Oliver Specht 2006-05-29 08:02:52 UTC
Target set to OOo 3.0
Comment 10 Oliver Specht 2006-06-20 13:44:13 UTC
Target adjusted
Comment 11 Mathias_Bauer 2008-01-11 13:00:40 UTC
target 3.x
Comment 12 2008-01-15 10:13:57 UTC
Pointer to issue 84684, which updates the situation after the recent changes regarding fontconfig 
Comment 13 Marcus 2017-05-20 11:31:33 UTC
Reset assigne to the default "".