Bug 64632 - FORMATTING: mtextra font needed even though it can be mapped to unicode
Summary: FORMATTING: mtextra font needed even though it can be mapped to unicode
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Sean Young
URL:
Whiteboard: target:4.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-15 12:56 UTC by Sean Young
Modified: 2013-05-27 12:42 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Document using MT Extra, search for "flag is set according to the result of the operation" (150.50 KB, application/msword)
2013-05-15 12:56 UTC, Sean Young
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sean Young 2013-05-15 12:56:23 UTC
Created attachment 79345 [details]
Document using MT Extra, search for "flag is set according to the result of the operation"

The MT Extra font is for glyphs used in mathtype, it does not have a standard mapping.

In the attached document, the mt extra font is used for the updown arrow ↕. This font is not installed on Fedora, so it not visible, however all characters[1] in this font can be mapped to unicode entries.

See the following table:

http://www.dessci.com/en/support/mathtype/tech/encodings/mtextra.htm

I'm not sure where this should be defined. There is an incomplete mapping for this font in unotools/source/misc/fontcvt.cxx line 648, but this is only used for document export, not display.

I'm not sure where this should be implemented; any hints for this would be welcome, I'm happy to work on a patch.

[1] With the exception of the Apple Logo
Comment 1 Caolán McNamara 2013-05-16 19:32:54 UTC
what should happen in general is that...
http://opengrok.libreoffice.org/xref/core/svtools/source/control/ctrltool.cxx#600 makeMissing should get a recode table for that uninstalled font, and force it to be known as a known "symbol" font if such a table exists.

Then when we go to draw with that font, http://opengrok.libreoffice.org/xref/core/vcl/source/gdi/outdev3.cxx#2294 should get hit and set the conversion table from mtextra to opensymbol with ConvertChar::GetRecodeData and we should then draw with opensymbol and run the points through the conversion table as we do so.

maybe an explicit

if (!pEntry->mpConversion &&
  aFontSelData.maTargetName.equalsIgnoreAsciiCase("mtextra"))
{
    pEntry->mpConversion = ConvertChar::GetRecodeData( OUString("MT Extra"),
        OUString("OpenSymbol") );
}
would help

or at least these are good places to start debugging, e.g. see if anything like the above is actually happening, and if it is find the contents of maTargetName and maSearchName when MT Extra comes around and see if any conversion table is set and if not, why not, and if so if the table is sufficient. Of course opensymbol might not have all the glyphs, that's possible too.

And in either case, completing/fixing the MTExtra table would be a good thing.
Comment 2 Sean Young 2013-05-26 08:26:49 UTC
Thanks. I've submitted two patches to solve this problem.

https://gerrit.libreoffice.org/#/c/4036/
https://gerrit.libreoffice.org/#/c/4037/
Comment 3 Commit Notification 2013-05-27 12:38:16 UTC
Sean Young committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4c831dd9e53163d75073c627c774f59fdaf9e874

fdo#64632 If a Symbol font is missing, ensure that conversion is done



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 4 Caolán McNamara 2013-05-27 12:42:17 UTC
Great thanks for these. Remember to send in the mail to the dev list stating that your code is under our preferred license combo.