RE: [libreoffice-users] RE: [Libreoffice] Word doesn't see symbols - Not Waiting for Perfection

Everything I said in my post is about available work-arounds and the current state of affairs, of 
course.

That seemed appropriate to address first, since it was an immediate problem for the users who have 
the problem.

To review the bidding:

  1. The problem that started this thread involves having a specialized font (although supplied in 
LibreOffice distributions) be available for working collaboratively in a situation where some 
participants use Microsoft Word and do not have LibreOffice (and the particular font) for whatever 
reason.  That is, we are talking about survival of embedded fonts, potentially, via conversion 
between ODF and another format such as any of the Microsoft Word formats (.doc and .docx).

  2. With regard to having embedded fonts in LibreOffice, the problem is that presently 
OpenDocument Format does not provide (clear) support for font embedding.  It is on the list of 
issues, but it has not been moved into activity for ODF 1.3 (the one now being worked on at OASIS). 
 Of course LibreOffice could come up with an OpenDocument Format extension for that purpose.  It 
would require some community work to have independent implementations of the ODF format recognize 
the extension and use it properly, but that is all achievable.  It is not going to happen overnight 
and, as far as I know, there is no work being done on this by LibreOffice developers.  One then 
needs to anticipate that the OASIS ODF solution might introduce a variance and future convergence 
becomes important.  Also, having converters that convey embedded fonts between an LO-specific 
extension and other extensions adds further complications.   (There are adopters of OpenDocument 
Format, both software producers and users, who require the document features to be promulgated in 
an International Standard.  Also, making a private or community extension brings some 
responsibility to provide documentation (e.g., implementation notes) that others can rely on in 
choosing how to interoperate.)

 3. With regard to consumers and producers (not the format), there are additional requirements for 
the smooth use of embedded fonts beyond correct rendering of a received document.  If collaboration 
is intended, there is the need for converters to work (including converters to and from WordPerfect 
format(s) of course).  In addition, for collaborative use to work, it needs to be possible to 
specify the font for use using the font dialogs and style definitions.  It also needs to be 
possible to select characters from the font using dialogs such as Insert | Special Character.  
There also need to be dialogs for importing and exporting embedded fonts and providing appropriate 
respect for licensing conditions conveyed with the fonts.  (Otherwise, there will be other reasons 
some organizations will forbid installation of LibreOffice or use of the feature because of 
liability issues.)

 4. Oh, and we need to address the existence of fonts that are now providing characters of Unicode 
Code points beyond U+FFFF.  This appears to work for current releases of LibreOffice, but it must 
also work for whatever the embedding mechanism is.

 5. There are probably other efforts that address font embedding. I would not be surprised to find 
it an issue at W3C, and we know there are provisions in PDF.  It might be valuable to rely on such 
existing work as much as possible.  And I suppose one needs to be alert for existing IP on the 
subject as well.

 - Dennis

-----Original Message-----
From: Roland Hughes [mailto:roland@logikalsolutions.com] 
Sent: Sunday, May 29, 2011 06:33
To: users@libreoffice.org
Cc: 'Deve'; 'plino'
Subject: Re: [libreoffice-users] RE: [Libreoffice] Word doesn't see symbols - More Analysis

Word Perfect solved this problem decades ago.  WPD format allowed for the complete embedding of 
fonts within the document.  Word Perfect used its own font rendering engine so as long as it had 
the complete font embedded in the document life was good, be it on Windows or OS/2 or OpenVMS.  
Yes, WordPerfect even had a version for OpenVMS.

On Sat, 2011-05-28 at 19:23 -0700, Dennis E. Hamilton wrote:

> Although the symptoms of font problems show up in the context of Word <-> LibreOffice Writer, the 
> situation is trickier than that.  It is exacerbated by failure to use standard Unicode code 
> points, eliminating the possibility of successful font substitutions, especially for symbols that 
> don't vary that much from one font to another and there is little danger of confusion.
>  
>  1. AVAILABLE FONTS
>
> Most office-productivity software products rely on the fonts installed on the operating system, 
> sharing those fonts with all software on the platform.  It is also the case that the installation 
> of software products will install fonts, optionally or automatically, for users on that computer. 
>   (Some fonts are only licensed to be used with the product or platform on which the product is 
> installed.)
>
> Users can also install an enormous variety of fonts of their own choosing, whether licensed from 
> a font foundry or obtained from one of the sources of unrestricted fonts.
>
> Example: Beside the fonts that are available on the platform directly, my main Windows 7 desktop 
> system has fonts installed by Microsoft Office 2010, Visual Studio 2010, Photoshop Elements, Word 
> Perfect X5 Standard, and LibreOffice 3.3.2, among others.  All of these fonts are available to 
> LibreOffice 3.3.2 Writer.
>
>  2. INTERCHANGING DOCUMENTS WITH FONT DEPENDENCIES
>
> When fonts use essentially the same code points for the same characters, but with differences in 
> font-face design, there are techniques to substitute a close kindred font when the specific font 
> is not available to the consumer of a document.  This might create problems with metrics, but 
> there are many fonts that substitute well enough.   Systems may provide automatic substitutions 
> for fonts that are not installed.  Products also have ways to let users direct the substitutions. 
>  
>
> Example:  In LibreOffice, the Tools | Options | LibreOffice | Fonts dialog provides for 
> substitutions.  The Help topic indicates the range of capabilties.
>
> Font substitutions don't work so well for decorative fonts and it is generally not possible for 
> symbol fonts that use special code pages (older systems) or non-standard Unicode code points for 
> their characters.
>
> Some fonts don't provide substitutions very well at all.  In particular, there is no assured 
> substitution for Unicode-based fonts that rely on code points in the Unicode Private Use Area, 
> U+E000 to U+F8FF.  
>
> Example: The Microsoft Symbol, Webdings, Wingdings, Wingdings2, and Wingdings 3 each use 
> private-use code points in the same range: U+F020 to F0FF.  U+F020 is always a space character, 
> but the other code points are not substitutable characters among those fonts.  Likewise, 
> OpenSymbol uses some standard Unicode code points but it also includes an extensive number of 
> code points in the private-use range U+E001 to U+E6A3.   These do not correspond to the use of 
> private-use code points by Linux Libertine G (a Serif Unicode-based font) and Linux Biolinum G (a 
> Sans Serif Unicode-based font).  None of these characters that have private-use code points are 
> substitutable among different symbol-only or Unicode-based fonts.  
>
> A significant number of the characters defined in the Private Use Area also have standard Unicode 
> code points.  The standard Unicode code points should always be used instead if fonts that 
> include them are available, such as Lucida Sans Unicode and Cambria Math.  Linux Biolinium G can 
> also be used this way so long as its Private Use Area characters are avoided.
>
> Generally, the greatest fidelity is obtained if it can be arranged to have the same font and font 
> metrics installed on the computer system of the document consumers as were used by the document 
> producer and on which the document depends.  
>
> For documents that use characters from the private use area of fonts available to the document 
> producer, the only prospect for successful interchange is if the document consumer has a font 
> that defines those very same characters at the same code points of the private use area.  This 
> has to be accomplished by private convention.
>
>  3. PROVIDING THE FONTS THAT A DOCUMENT DEPENDS ON
>
> If the same software is used by the producer and consumer, there is no difficulty when fonts 
> consistently-supplied with the software, are used even if the platforms are different.
>
> If the font has a different source, or different software is being used, there needs to be 
> another way to provide the necessary font for use by the consumer.
>
> There are two ways to do this:
>
>     - Using a document format that embeds the fonts
>
>     - Transferring font files to the other computer system
>
> 4. USING EMBEDDED FONTS IN AN INTERCHANGE DOCUMENT
>
> A common method for ensuring that the consumer will view the document with fidelity to the 
> document that was produced is to export Adobe PDF documents.  These documents can carry embedded 
> fonts and it is possible to arrange production of bitmap versions of characters when the font is 
> not embeddable.
>
> Microsoft Word documents can also carry embedded fonts.  This allows for correct viewing by a 
> recipient as well.
>
> In general, having an embedded font in a document is not the same as having it available for use 
> in other documents.  There are also barriers to using the font in further collaborative editing 
> of the same document.  There are manual workarounds that experts might employ, but those are 
> probably too tedious for anything but rare occasions.
>
> Also, if the collaborative interchange is between different products, embedded fonts won't be 
> enough.  The odds of passing embedded fonts through a converter are rather low at this point.  
> The possibility of round-trip preservation of embedded fonts by conversion in both directions is 
> even more remote.
>
> Example: ODF lacks an agreed means for embedding of fonts.  Word saving of documents with 
> embedded fonts as ODF text documents loses the embedded fonts.  (If the receiving ODF consumer 
> has the fonts, it will still work though.)  LibreOffice could provide font embedding as part of 
> Save As Word format, but the current converters do not provide that capability.  Also, even with 
> an embedded font, it may be cumbersome to use that font in further editing of the received 
> document unless the embedded font can be installed on the receiving system by some means.
>
> 5. TRANSFERRING FONTS TO ANOTHER COMPUTER SYSTEM
>
> One way to transfer fonts is to install a software application that provides them.
>
> This is not so far-fetched.  LibreOffice can be installed for free, with minimum configuration, 
> simply to obtain its unique fonts.   It is not necessary to run it.  We just want to have a 
> common set of fonts.  
>
> Another way is to package and transfer fonts for mutual installation and agreed use.   Fonts are 
> not difficult to install.  It is likely that the LibreOffice fonts are more amenable to 
> unrestricted transfer onto other computers.  This may be the only way of adding fonts into some 
> controlled computer configurations.
>
> Round trip collaboration also requires agreement to use only fonts that are arranged to be 
> available on any of the computers and software products used among the collaborators.   Users 
> will need to understand how to limit themselves to use of mutually-available fonts and to avoid 
> pitfalls such as relying on characters in the Private Use Area instead of their standard Unicode 
> code-point positions when those are mutually supported.
>
> The limitation to mutual agreed use is the tricky part, since it requires users to be aware of 
> and careful of the conditions that assure mutual success.
>
> 6. FOR LIBREOFFICE DEVELOPERS
>
> It is unfortunate that there are so many uses of the Private Use Area 
> at large in the world.  It would be valuable to avoid distributing 
> more files that rely on them.  (The existing conflict between Open 
> Symbol and Linux Biolinum/Libertine G is amusing enough.)
>
>   a. It would be useful to update OpenSymbol to use the now-standard code Unicode code points for 
> those characters that were previously unavailable as standard characters.
>
>  b. It would also be useful to document the usage of the Private Use Area by fonts distributed 
> with LibreOffice.  A PDF that shows the code points and character appearance would be an 
> excellent way to make these known, so people would be informed on the impact their usage has for 
> interchange with other systems and conversion to other formats.
>
>  c. It would be especially valuable to adjust the LibreOffice repertoire of bullet symbols, 
> especially those used by default, to avoid using code points in the Private Use Area for those 
> characters.
>
>  - Dennis
>
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Friday, May 27, 2011 13:53
> To: 'Deve'; 'libreoffice@lists.freedesktop.org'
> Cc: 'LOffice Users List'
> Subject: RE: [Libreoffice] Word doesn't see symbols - NEW PROBLEM
>
> There's a new problem.  I checked around for middle dots, centered dots, etc.
>
> The SAFE one is U+22C5, the Middle Dot in the extensive Unicode block on Mathematical Operators, 
> from U+2200 to U+22FF.
>
> The dots that I saw in OpenSymbol are these: U+E146, U+E468, U+E466, U+E58D, and U+E584.  My copy 
> of the Unicode Standard 4.0 says that these are all PRIVATE USE SYMBOLS.   This Private Use Area 
> has existed since at least Unicode 3.2 and is unchanged in Unicode 6.0.  See 
> <http://www.unicode.org/charts/>.
>
> "These areas will never be defined by the Unicode Standard.  These code points can be freely used 
> for characters of any purpose, but successful interchange requires an agreement between sender 
> and receiver on their interpretation."  
>
> Furthermore, the codes extending upward from U+E000 are intended for END-USER assignment and the 
> codes extending downward from U+F8FF are intended for CORPORATE USE (including vendors, platform 
> providers, etc.), the idea that the chance of collision is reduced thereby.   This is only a 
> suggested convention, however.
>
> These depend on private agreements for having matching fonts or even being used for visible 
> characters.  Something tells me you'll be hard-pressed to find these in fonts on Windows unless 
> you can send the OpenSymbol font to the recipient.  
>
> [ ... ]
>
> My recommendation is to use a defined Unicode character (and a font that supports it) in 
> preference to the same OpenSymbol character whenever possible.
>
>  - Dennis
>
> [ ... ]


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net

No U.S. troops have ever lost their lives defending our ethanol reserves.

--
Unsubscribe instructions: E-mail to users+help@libreoffice.org Posting guidelines + more: 
http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/www/users/
All messages sent to this list will be publicly archived and cannot be deleted


-- 
Unsubscribe instructions: E-mail to users+help@libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/www/users/
All messages sent to this list will be publicly archived and cannot be deleted