Apache OpenOffice (AOO) Bugzilla – Issue 58535
OutputDevice::GetDefaultFont() seems to return a font name listed in VCL.xcu
Last modified: 2017-05-20 11:31:33 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.
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".