There’s ‘Bug 42195 - Support for embedded fonts is missing’ → fdo#42195
Bug 42195 - Writer FILEOPEN functionality request: add Support for embedded fonts
Status: RESOLVED FIXED · Target: LO 4.1.0
Follow-up 1: Bug 61072 - Impress, functionality request: add Support for embedded fonts in .odp file format
Follow-up 2: Bug 61073 - Calc, functionality request: add Support for embedded fonts in .ods file format
fdo#61072, fdo#61073
Status: RESOLVED FIXED · Target: LO 4.1.0
See also → LibreOffice 4.1 ReleaseNotes
As I told @pedro a few times, he is wrong, ODF v1.0 supports the functionality and now there is a LibreOffice implementation with a release pending. Good work !
As written in Liberation fonts homepage:
“The Liberation™ Fonts is a font family which aims at metric compatibility with Arial, Times New Roman, and Courier New.”
A document written with Liberation fonts should be formatted exactly the same when viewed using standard Windows fonts.
Keyword “aims” - it’s close enough, but not perfect. That means I always need to include a small explanation and a link for the recipient to install the fonts on their own. It’s a one-time operation but it’s often inconvenient and takes time & access/knowledge to do it.
While I really DO like Libreoffice… the lack of font embedding cuts it out of being able to transfer all my work out of dead and dying formats or the use of proprietary software from companies who I regards as scumbags.
Any product I create via Libre Office be it document, artwork, engineering drawings or presentations etc., done in LO with your own font sets, cannot be transferred via dual booting between Linux or Windows, or it cannot be transferred to a different machine - from home to work or vis versa, and one cannot transfer the work to an independent third party such as peer review, or be sent to the printers, and the product cannot be archived and reopened on a different computer - because ANY work done ON a specific computer with ones own specific font sets, will be completely lost - because the original fonts, on the original machine, are not embedded in the documents produced on that machine.
QED - it’s an Epic Failure.
With Open Office and the blooming fork, Libre Office, people have been raising these issues for 20 years, and for 20 years the committees, forum administrators, bugzilla forums, have ALL ignored and shut down any discussion or progress towards making font embedding the defacto or default setting.
While Microsoft, Word Perfect, Adobe and even really obscure office programs such as Abi office, etc., etc., etc. - they ALL have font embedding.
So the Open Office and Libre Office products and the committees that all drive these programs - have an epic failure on their hands and they are doing NOTHING to address it.
Have a read up on this topic via the article…
http://fuckubuntu.blogspot.com.au/2011/06/open-office-office-libre-font-embedding.html
It is not a LibreOffice/TDF’s goal to provide a free office suit that perpetuates Microsoft’s closed and proprietary file formats. So any change on font embedding has to occur on the ODF file format.
ODF 1.2 still doesn’t support font embedding but it is being considered http://tinyurl.com/6vp2w5d
I am not a licensing expert, but embedding proprietary fonts into document probably raises licensing issues.
I also think this embedding is very important, but on the other hand it should not be implemented into ODF something that is not standards supported. Don’t want to have multiple products each supporting its own version of ODF - you know just like a HTML history big mess.
I am not a licensing expert, but embedding proprietary fonts into document probably raises licensing issues.
If you can live with PDF then you can embed fonts in it.
So guys…why not think about this the other way around. Upon install, LO x.y installs a known stable family of fonts on the system (LO_arial, LO_timesroman, etc). Add something to tools that sets priorities between platform fonts and LO installed fonts (try platform first then try LO fonts or vice versa or one/other ONLY).
On opening a doc, create or use some variables for fonts to be used. If older doc, create and save (aka like user credentials - name address etc). New or reopened doc, use those variables. If fonts not found, kick up msgbox to user about how to proceed. Somebody adds some cool text to document using font Z, update table in the font variables to include (since presumably this would default to one of the LO installed fonts, so still universal).
At least that would be consistent across all LO installs at X.Y or later. If document foundation guys spend too much time studying the need for this, LO reach out to OO etc and see if all can agree on approach. MS can choose to join the party or not.
I realize I may be overly simplifying this…but does get around having to all the actual fonts with the document.
Visio has done something similar for 10 years…though their approach has a limitation surrounding it in that its based on the relative offset of the font in the library from #1 (i.e On system A, #33 might be font X…on system B, #33 might be font Y). All I am suggesting is that instead of relative index, use actual font name.
I am planning to work on a fork of LO / OO and implement font embedding. But before I do that, I want to know if it’s going to be worth it. So please answer the following questions:
- As a consumer, will you switch to my new fork and start using my version just because it has font embedding?
- As a developer, will you switch to my new fork and start contributing to this new fork instead, just because it has font embedding?
If I get 1,000 positive replies, I will start the fork.
I think it would be much more productive if you added your effort to one of the existing suites. As a user, font embedding is reason enough to make me switch, but I think it is not a reason to start a fork and divide even more the developer effort.
There is no need to fork a whole product to add tiny functionality. Why not build a plug-in instead? When a LOT of users will have this plug-in, support will be added into main product…
No need to fork anymore. It is already implemented and will ship with LibreOffice v4.1 around July 2013. Rejoice \o/