Created attachment 22749 [details]
Writer document with Minion Pro

Created attachment 22750 [details]
PDF export with the missing font

Created attachment 22751 [details]
Writer document with Minion Pro

cp->pl: please have a look

pl->hdu: and again type 1 on windows; also would this work on Linux ? we'd have
to extract a type1 there if possible.

Being able to embed or subset also fonts with CFF glyph outlines would indeed be
a nice feature.

By the way, I have installed the last version (1.9.87) on my Linux box and it
doesn't evem recognize the Minion Pro font (this bug has been already reported).

The PDF export should be able to handle Postscript fonts properly. Partial
embedding is one of the required features but no the only one (proper embedding
is needed first). I don't have a deep knowledge of the PDF generation process,
but since Ghostview is an interpreter and does it task right, I think that
taking a look at its code (no to copy it, but only to see how it could work)
would be great.

*** Issue 50522 has been marked as a duplicate of this issue. ***

I have just run into the same problem.  Writer embedded an OpenType font with 
truetype outlines, but two Adobe OpenType fonts with Postscript outlines were 
substituted by a flavor of Times New Roman.  I would send samples but I believe 
it's not Kosher to post the Adobe fonts on the web.  In any case, I can verify 
the problem and attest to its utmost extremity of unsettlingnessness.

Thank you.

Hmmmm...  I have a Question.  Shouldn't this "feature" be a "defect" if the 
issue makes Export to PDF unusable for the end user?  That is to say, isn't the 
PDF feature somewhat useless to large groups of people if it can't interpret 
widely used fonts that ship with industry standard applications, such as 
Illustrator?

Dupe of issue 10218?

> Dupe of issue 10218

Related but not duplicate...

To work around this bug, I use extendedPDF :
http://www.3bview.com/pages/epdf-download.php
It's a little difficult to install, but Opentype fonts with PS outlines ou PS
fonts are correctly embedded into the PDF File.
Hope it can help.

Thanks, Xavier. It is a workaround, but not being able to embed the right glyphs
is not an enhancement (as it would be the font subsetting), but a real bug.

I've hit the same problem using Zapfino Extra. This is a show-stopper for me,
and it's particularly serious because you might only find out about it after
spending a lot of time working on a document, just as you're about to send it to
the bureau for printing.

This is also about oo.o not yet supporting .otf files since that's how all the
Adobe pro fonts are sold now. This is mentioned at issue 16032
http://www.openoffice.org/issues/show_bug.cgi?id=16032 as an enhancement
request. The best workaround currently is to convert your .otf files to ttf with
software like fontforge http://fontforge.sourceforge.net/ . Note that conversion
to ttf means all hinting from the professional otf font will be lost since it's
an incompatible format, and the automated ttf hinting in fontforge is pretty
much useless currently. However the printed fonts still look excellent as
hinting is really only relevant on screens and printing ultra small fonts I
believe. Nonetheless it would be nice if oo.o supported .otf files for both
rendering and their extra features since freetype works fine with them.

*** Issue 72697 has been marked as a duplicate of this issue. ***

I also have just the same problem with all open-Type-fonts which were included 
in the Adobe CreativeSuite 2, i.g. Minion Pro, Caslon Pro, Jenson Pro, Caparral 
Pro, Courier Std and Gozuka Gothic Pro. Only Adobe Garamond works well.

In my opinion this is a defect and not a feature. This is really a show stopper
for using OpenOffice. The suggested workarounds are not end-user friendly and
moreover ttf fonts cannot contain the complete character set from the otf version.

No one said this is a feature. We're just waiting patiently for support.

Adjusted the issue summary to help bug reporters find duplicates.

*** Issue 75271 has been marked as a duplicate of this issue. ***

I wonder if the two problems discussed in this issue:
(1) support for OTF font embedding in PDFs, and
(2) complete lack of OTF support under Linux
shouldn't be separated.

The summary of the issue only refers to the first problem. The second problem, 
that under Linux you can't use OTF fonts at all (although other Linux 
applications can use them) seems to me even more serious, specially as Ubuntu 
with a lot of  OTF fonts by default. The number of OTF fonts increases 
continually, not only Adobe has completely switched to OTF, but also many free 
fonts are published as OTF, like Jos Buivenga's fonts, the Greek Font Society 
etc.

@menetegel: Good idea! I split off issue 78858 (just displaying PS-OpenType fonts)

I don't understand. How is just displaying them without being able to print them
of any use? Doesn't this just dilute the copious votes this issue is getting
even further?

@ckolivas: Being able to display and measure them is just an important first step. I don't think people 
should dilute their votes for the other issue.

*** Issue 82703 has been marked as a duplicate of this issue. ***

I agree with jdefouw. This is a show stopper for me because I have many
OpenType-Postscript outline fonts. I find it hard to use document software that
limit the use of fonts I have purchased.

I say this with much regret because I have been a vocal proponent of OO since
its days as Star Office. It is, of course, also regrettable because otherwise, I
much prefer OO Writer over MS Word.

Note that the STIX project (http://www.stixfonts.org/) just released a first
version of its scientific and engineering fonts after 12 years of work, a lot of
their glyphs are not present in common fonts (only in very expensive commercial
fonts), so anyone doing scientific or engineering work on FLOSS systems (where
OO.o is common) is going to use them.

And guess what? they're OTF fonts with Postscript outlines.

Please note, that issue 31764 (Need to support GPOS kerning) is linked to this
issue. The GPOS-table must also be interpreted for TrueType-fonts (which are not
directly mentioned here.) It might be therefore useful to change the summary
field to: "support basic OpenType and postscript outline fonts for PDF export
and printing" or to create a seperate issue on this, though I'd recommend (due
to the fact that OpenType tables are the same for TrueType and PS/CFF
OpenType-fonts) to see this problem as one issue.

We had to convert Rachana Malayalam OpenType Font to a TrueType font just for
being able to use in OpenOffice (It works in every other application). I have
also voted for this fix.

I can't use anymore votes on this issue, but I believe it should have much
higher priority, so I thought I would comment. OpenType is pretty much the
standard at this point, and it's really worrisome to me that OO doesn't support
it fully. I love OO, but this is a big problem and has caused me to have to use
other software at times. 

I have to agree with merkri. This issue has caused me to move back to MS Word
after years of primarily using OO Writer. It doesn't make sense for me to give
up font choices to use OO Writer, even though OO Writer is vastly superior in
many other ways. If I could cast more votes for this issue, I would.

Yes, the lack of OTF support is a real show stopper. Given, that there's a large
open source code base out ther, which is able to cope with OpenType/CFF (e.g.
freetype) is should be possible to tackle this issue within a fair amount of time.

This bug is already three years old. The milestone is targeted for later. The
question that arises here is: later than what? Later than version 3.0?

I don't know whether this is the most important/critical issue that OOo has. But
not being able to use OpenType fonts (althought it seems that they will be
displayed in OOo 3.0) makes OOo less usable.

Just in case it might help, I think that considering cairo for efficient PDF
generation would be interesting and helpful. But I wonder whether cairo could
generate hybrid PDF files.

Thanks, Pablo.

More votes for this issue. I sympathise with the previous poster's frustration
at seeing this defect milestoned as "OOo Later". Three years ago there may still
have been a little bit of scepticism regarding OTF, but there's no question now
about it not being the standard. We're not asking for OpenType *feature* support
on this issue, just the ability to embed OTFs in exported PDFs, which is
something that any PDF-printer-driver program can do (eg PDFCreator).

This should not be flagged as feature but DEFECT.

At the very least the blurb writers could be a little more honest when flaunting
OOo's PDF export feature, but somehow I doubt that "The PDF export feature will
screw up your layout unless you only use TrueType fonts" is quite so attractive
to potential punters.

Grrrrr...

Yes. It's much more important than most of other bugs. Much times, I have
destroyed PDFs - I'm forced to use a PDF-printer, but there's nothing like
clickeable links, headlines as navigation a.s.o. IMHO is the priority to low,
because this is a real bug/defect.

Although I also think that the current situation is unsatisfying, I want to
remind my fellow users of our issue description guidelines (just click above on
the links “issue type”, “priority”, and so on): this IS an issue of the type
“feature” and of the priority “3”.

And what makes things worse is not the fact that this issue is open for more
than 3 years now, but that 3 years ago Adobe announced to “phase out” PostScript
Type 1 fonts and to target only on OpenType fonts, and that hence OOo must
support OpenType fonts just as it supported (and sill supports) Type 1 fonts.

Thus I also feel that the target “later” does not reflect the community's wishes
and prioritizing for OpenType support appropriately.

On the Linux side I can tell you the majority of the new fonts we've integrated
in Fedora these past months were OTF fonts, and at the same time a lot of old
unmaintained Type1 fonts were dropped from the distribution.

The the switch to OTF is pretty much already happening on our platform. OTF
fonts work everywhere except for OO.o

What can the community do to help with this issue in a more active way?

There have been several similar cases in other FOSS projects as well (for
example, in Firefox) where bugs have been bugging us for years.

If we were to get a contributor/developer to work on this, what would they have
to do? On which part of the code tree would they need to look?

> What can the community do to help with this issue in a more active way?

Implement font subsetting for CFF based OpenType fonts that is suitable for PS printing and PDF 
export.

> On which part of the code tree would they need to look?

1. CFF subsetting (http://gsl.openoffice.org/source/browse/gsl/psprint/source/fontsubset/)
2. PS printing (http://gsl.openoffice.org/source/browse/gsl/vcl/unx/source/gdi/pspgraphics.cxx)
3. PDF export (http://gsl.openoffice.org/source/browse/gsl/vcl/source/gdi/pdfwriter_impl.cxx)

Hope this helps.

> > What can the community do to help with this issue in a more active way?
> Implement font subsetting for CFF based OpenType fonts that is suitable for PS
> printing and PDF export.

Done:

http://gitweb.freedesktop.org/?p=cairo;a=blob;h=53c5a175dffc11f038c6ea07dc709c80ef80e073;hb=9166686abd92f8b2c7067002b051220e2f8fe780;f=src/cairo-cff-subset.c

Licensed under MPL/LGPL or ask me if you want a different license.

All you have to do is integrate the code into OpenOffice.

@nmailhot: Fedora is replacing its Type1 fonts by their CFF-OTF counterparts? That is very interesting 
and changes the priority of the feature request.

@adrianjohnson: good to see you here. Welcome!

I had a closer look at the PS export and especially its font handling. For CFF fonts the fallback method 
seems to be used: The glyph outlines get wrapped into a Type1, but hints are lost. Of course hints in 
Type1 fonts are not as important as for TTFs, but since the conversion between CFF and Type1 can be 
done without any loss, I was hoping for that. I already have some code that does that, but it is not 
reliable enough yet. If we need a quick solution the fallback to outlines seems to be a reasonable 
alternative though. On the other hand experts advocating CFF outlines over TTF outlines seem to be 
extremely sensitive about this topic.

The full-CFF to subset-CFF conversion used in cairo's PDF export is very nice indeed. Thanks for the 
pointer! We'll need CFF-subsetting on Windows too, but don't have any use for other parts of cairo on 
that platform yet. There are not too many deep dependencies into cairo's infrastructure, so if breaking 
this part out is technically feasible I'd like to do it, if you agree.

hdu> @nmailhot: Fedora is replacing its Type1 fonts by their CFF-OTF
counterparts? hdu> That is very interesting and changes the priority of the
feature request.

It's not a project goal but has been happening de facto lately. Active font
projects use TTF or OTF format. In fact except for projects that specifically
target OO.o on Linux, OTF is the default format for new fonts, because it's the
default in font creation tools (both open and closed).

Therefore the number of shipped OTF fonts grows. OTF works well in every major
Linux GUI app but OO.o.

At the same time if a font still uses the Type1 format, that's because no one is
working on it. Therefore any new problem report (technical or legal) can lead to
the conclusion there's no one to fix it. Since Fedora does not ship unmaintained
material, the direct result is that the font gets pulled. Unlike a few years ago
we have alternatives font-side, so problematic Type1 fonts (such as the ones
that used to be bundled with Xorg) are not tolerated anymore.

> I had a closer look at the PS export and especially its font
> handling. For CFF fonts the fallback method seems to be used: The
> glyph outlines get wrapped into a Type1, but hints are lost. Of course
> hints in Type1 fonts are not as important as for TTFs, but since the
> conversion between CFF and Type1 can be done without any loss, I was
> hoping for that. I already have some code that does that, but it is
> not reliable enough yet. If we need a quick solution the fallback to
> outlines seems to be a reasonable alternative though. On the other
> hand experts advocating CFF outlines over TTF outlines seem to be
> extremely sensitive about this topic.

Yes, subsetting CFF to Type 1 would be better. I looked into this when
I wrote the CFF subsetting but never got around to actually writing any
code. Preserving the hinting in PDF was the priority while subsetting
CFF to Type 1 for PS was in the "nice to have" category.

> The full-CFF to subset-CFF conversion used in cairo's PDF export is
> very nice indeed. Thanks for the pointer! We'll need CFF-subsetting on
> Windows too, but don't have any use for other parts of cairo on that
> platform yet. There are not too many deep dependencies into cairo's
> infrastructure, so if breaking this part out is technically feasible
> I'd like to do it, if you agree.

You are welcome to use the code. I am interested in seeing free
software have full support for OTF/CFF fonts. The only dependencies I
am aware of are cairo-array.c and cairo-hash.c. Of course it would
also be nice for cairo to receive any bug fixes and enhancements you
make to the code.

I have been thinking about whether adding API to cairo to expose the
font subsetting code would be useful. I don't know if anything like
that would be useful to you. However breaking out whatever you need
is probably the easiest solution.

PDF export and printing of PostScript fonts would be an interesting feature to
have on version 3.

Will this feature be available in version 3?

Thanks,


Pablo

mbayer->ousia: As you can deduce from this issue's target milestone “OOo Later”,
the feature requested won't be available in one of OOo's releases in the near
future. For further inquiries, please contact the dev@gsl.openoffice.org mailing
list.

I am generally very patient with open source projects; however, I am
increasingly frustrated with this issue. It was opened over 3 years ago, is
still marked as "OO Later" and is not scheduled for 00 version 3. Are we to
assume that this bug will not be fixed until OO version 4?

As has been pointed out, this is not a "nice to have" feature. It is a
capability that has been available for many years in commercial products. For
some reason, I still start projects with OO Writer. At some point, I become
frustrated that I have many entire font families that I cannot use in OO. Then,
I give up and fall back to MS Word. 

jurf has pointed out that, with regard to this defect, OO should reconsider its
claim for PDF export capabilities. Also, it has been pointed out by several
members that this issue should be classified as a bug, given that the behavior
is not at all what a user might expect. OTF fonts have become standard in
Fedora. Sadly, in my opinion this defect is not as severe as the widely reported
bug regarding PS fonts in MS Vista.

I cannot understand why this issue has not been elevated to defect. Also, I do
not understand why, after 3 years, this issue still has no target date for a
fix. As a member of OS projects, I know that resources are limited; however, the
concern of many members seems to be that this issue has had a lower priority
than is reasonable.

I agree with burmashave: I too do not understand why this issue has not been
reclassified as a defect. It is way past the point where is could be called an RFE.

I cannot use OpenOffice at work unless is seamlessly supports Microsoft format
documents, and they support OTF.

Note: My version of KWord (1.6.3) supports OTF.

The real point is not if it fits the definition of defect. It is, instead, the
urgency that is requests. See? Not being a defect doesn't exclude the
possibility of being urgent (in general yes, but it shouldn't always, according
to any reason). That's why:

Read Writer Guide, chapter five, third edition. Available at:

http://documentation.openoffice.org/manuals/oooauthors2/

1- On page 145, it says without any exceptions that OOo can export documents to
PDF. It's widely advertised as a PDF-capable program... you can clearly see that
the publicity doesn't say anything about incapable of dealing with this or that
font format. And OTF-PS is not a niche font format by any means, so even common
sense  would not apply (to justify the lack of remarks). So there should be at
least remarks.

2- Also, at least on Windows, OTF-PS fonts are displayed just fine but PDF
export is done without any warning... the problem is not the lack of support,
but the fact that if one doesn't check the PDF (in a hurry to e-mail it), you
can't know that the document will be completely different from the original (Times).

3- This is also, in my opinion, very bad for the program image as a whole... on
point 2, people will wonder if Writer may misbehave on other things as well,
without warning them.

So, there are indeed "features" that are more urgent than many "defects" out there.

So how do we users go about raising the priority of this issue to P2?

I've had PDF (which I thought meant "safe") copies of my résumé go out with
mangled fonts.  This is becoming an issue important enough that I'm considering
purchasing one of the commercial suites.

I have raised the priority to P2. Ad added two votes (because I'm not allowed to
spend more votes on this issue).

As already said, neither changing this issue's type from “Enhancement” to
“Defect”, nor setting it's priority to an arbitrary value, nor holding
discussions in this issue at all is productive.

Instead, please start a discussion on the discuss@ux.openoffice.org mailing
list, in order to convince the UX team to recommend this issue for development.

I subscribed to the list, at
http://ux.openoffice.org/servlets/ProjectMailingListList

(apparently there are a few "discuss"@ mailing lists from different subprojects).

I reported this to the discuss@ux.openofffice.org on Friday,
http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=1852
There was no reply yet (probably due to weekend).

It might be good to chip in the discussion.

Exporting an Impress file with ArnoPro font but PDF shows a cracky Arial after
export.

After some discussion, the consensus Fedora-side seems to be that shipping
OpenType TT (as opposed to OpenType CFF) fonts just for OpenOffice is not
reasonable, so all our future font packages are likely to use the font creator
preferred format (which happens to be OpenType CFF, don't ask me why, I blame
Adobe years of marketing)

http://www.redhat.com/archives/fedora-fonts-list/2008-July/msg00088.html

The good news is that CFF subsetting looks good for OOo 3.2, maybe even 3.1. Including hints and all 
that. Though CFF fonts may be common they are strange beasts, e.g. the length of some charstring 
opcodes depends on all instructions ever executed for one glyph and there are sooo many other implicit 
assumptions... anyway, the prototype works very well and getting it integrated into 3.x is quite certain.

Thank you for the status update!

Big thanks for finally announcing a target milestone ;-)

My vote for OOo-3.1, since many users expected this feature to already appear in 3.0

  Best regards,

    Wolfgang

Thanks for announcing the milestone, hdu! Thanks to all the dev's, etc. who are
moving this forward. We appreciate it very much.

Yes, very glad to see this getting worked on. Thanks very much to everyone
helping to make this happen.

Unless I'm mistaken, OOo is using ICU. There's a TeX derivative called XeTeX
(http://scripts.sil.org/xetex) that (on Linux and Windows) uses a modified
version of ICU over fontconfig and freetype to access and "render"
system-installed OpenType fonts. I put render in quotes since XeTeX doesn't
really draw the glyphs, but it does need to determine font metrics etc. XeTeX
supports both flavors of OpenType equally well, and it has *full* support for
OpenType layout features: you can set any feature tag directly if you like and
there's also an abstraction layer.

It may be worth looking at, especially for ICU modifications...

I'm glad to see work on this issue has started. I just put money down for a
widely-known commercial productivity suite because OOo doesn't let me format,
print, and save to PDF even English-language text with CFF-flavour OpenType
fonts (*.otf). 

This bug was a deal-breaker for me.  My preferred fonts for English-language
letters, reports, and other business documents are all CFF-flavour OpenType.  I
regret that it took 3 years to get it into implementation.

vga, Can I download and install XeTeX into my Linux, and after this I would use
any "PS outlined" opentype font on my OOo? Hassle free?

@lcdsantos,

What XeTeX can and cannot do is independent of what OOo can and cannot do. They
are two different programs, each with different capabilities, written for
different purposes. (OOo is a productivity suite that includes a word processor,
and XeTeX is a high quality page description language that can use OpenType fonts.)

So the answer to your questions, "No."

Installing XeTeX allows you to use OpenType fonts *only if they are already
present on your system* and only if you also have TeX/LaTeX installed. OOo
cannot use OpenType fonts currently, regardless of which fonts are installed.

Support for OTF (with CFF) is "a must". Hope soon have some certain good news
about it.

You were mentioned on /., BTW:
http://tech.slashdot.org/tech/08/10/11/227236.shtml

I just noticed that using OpenType fonts with PostScript outlines on Linux will
not be in 3.1. I have given this issue 2 votes. I am not a programmer so I can't
help with the code necessary to implement this, but is there anything else I can
do? Money? Bribes? A .357 magnum? I'll do anything I can to help.

This issue is already 4yo (although the issue 16032 will be 6yo this June, so
the issue is already 5yo).

I don't know how many other issues have more votes than this, but having 237 is
not bad (412 considering the votes for 16032).

Code has been provided to fix the issue, although it needs to be adapted.

Sorry for not being able to code the patch that will fix this issue.

But once the target milestone has been set for release 3.2, please keep it so.
Delay this release as long as it might take to fix the issue, but please, do not
postpone this issue for a latter milestone.

Thanks for your help,


Pablo

Looks good for 3.2... unless other high priorities like the Mac-Port, DrawingLayer rework, BiDi+CTL 
issues, Vista issues, bad but subtle regressions introduced by fontconfig- and cairo-integration, I18N 
issues etc. get in the way again...

Big hads hdu ;-)

  This sounds really good. This issue is too old in order to further postpone it. 

Many, many, many thank in advance,

  Wolfgang

Since version 3.1 has already been released, the next stable version 3.2 will
have this issue solved, won't it?

Thanks for your help,


Pablo

.

Childworkspace "otf01" looks good for a OOo 3.2 target.

Je cherchais justement comment obtenir cette possibilité. Dommage que ce ne soit
pas possible. J'ai voté, mais le développement n'étant pas démocratique, ce n'a
probablement aucun effet (voir le
[url=http://qa.openoffice.org/issues/show_bug.cgi?id=43029]le bug sur l'export
PDF des polices OpenType[/url] dont la correction est sans cesse repoussée
malgré les 250 votes).

*** Issue 104011 has been marked as a duplicate of this issue. ***

regaring issue nr. 104011 i have exported the file with OO DEV300m53 (Build
9412) to pdf, but no improvements.

Relating to previous OO versions, i could export the same document to pdf with
OO version 210 with no problems. But from version 221 onwards fonts have
problems in pdf.

Created attachment 63976 [details]
issue 104011: document of oo 2.1.0

Created attachment 63977 [details]
issue 104011: document of oo 2.1.0 (correct pdf export)

Done in CWS otf01.
The biggest part was the glue code to the existing PDF-export and PS-printer code.
Another interesting detail is that small text prints well also on older printer (with PSLL<3) as the hints are 
preserved.

@es: please verify in CWS otf01 (printing on UNX, PDF-export on WIN/UNX/OSX)

Great news!!! I would like to test it. Could you please confirm the version
where is it fixed. Is it the develoment version "OOo-Dev 3.2.x"? (for linux debian)
http://openoffice.bouncer.osuosl.org/?product=OOo-Dev&os=linuxinteldeb&lang=en-US&version=DEV300_m55
Sorry the ignorance.

@ferrosan:
read the release notes here
http://download.openoffice.org/next/other.html#dev2
to see if the CWS is included in the last release.

You can also check what is the status of the CWS in:
http://tools.services.openoffice.org/EIS2/GuestLogon

Child Workspace > browse > per release > OOo 3.2
The CWS otf01 is now in the folder "ready for QA"
After a CWS is "integrated", the feature (or the bug fix) is usually found in
the next developer release.

Hi!

I am QA Representative for the the CWS otf01.
We decided make this CWS install sets public in order for every one to check the
fix *before* integration.

Install sets can be found here:
ftp://qa-upload.services.openoffice.org/otf01

Please give your feedback.
Try to see if something is broken. Bugs which already existed before the CWS
shouldn't be discussed here. Please write new issues for them.
Features or further implementation should also be handled in separated issue.

Thank you!

Not sure if this must be discussed here or elsewhere... The otf support on this
build seems to be partial: the otf fonts are recognized but their advanced
features (like ligatures) are not used. Also, when I export to pdf the font is
embed as "type 1"

Created attachment 64268 [details]
In the attached image the top string is from kword 2.0.1 while bottom is from OOo, both using the same otf font: linux libertine O

The issue with the optional OpenType features is already tracked in issue 16032. Let's focus on the 
WYSIWIG aspect of printing and PDF embedding here.

The fonts are subsetted to Type1 because the PS-printing code and the PDF-exporter have not been 
extended to support CFF-embedding yet. Since some important PS-printers do not support CFF-subsets 
being able to do it via Type1 is required anyway. And the subset is about the same size.

There'll be a task for PS-printing and PDF-export to support CFF-subsets, but that is another issue. Let's 
focus on the WYSIWIG aspect of using PS-OTF in printing and PDF embedding here.

Type 1 subsets are OK sinds Adobe do's the same thing and thats still the 
standard for Proffesional Printing !
However there is something wrong with the "kerning" between words and 
characters. As far i can see the OO-kerning settings are totaly ignored with 
results in to large or to small line lenghts.  

Created attachment 64269 [details]
odf for Professional Printing after PDF shows Kerning problems

I'm sorry to say it, but in the Mac version (OOo 3.2.0 / DEV300m55 / Build 9418 running on an intel Mac 
with OS 10.5.8) nothing is fixed.

The regular PDF-export of documents that use OpenType fonts produces only garbage, just like in all the 
previous versions.


@ sos
OOo is not meant for professional layout anyway.
;)

@foniq
I did not mentioned Layout but Professional "Printing" like Books and Magazines.
We produces over 6.000 full color Trade Magazine Pages/year. Just using OO-
writer and Adobe Acrobat for the PDF output :-) 

Good results under Ubuntu 9.04 and OOo Build 9418. OTFs are seen fine on screen
and prints very well on PDF's. Regarding to kerning problems, not seems to
appear here, not at least in a preliminary review.
@sos: Are you using the OOo Windows version?

To ALL: PLEASE READ:

The meaning of providing install set before integration was not to make this
issue longer than it already is but to get exact descriptions about
*regressions* and *failed fix*.

If you find the same problems as before please describe:
- your system (which OS)
- which font(s) are used
- whether PDF and/or printing are affected
- Attach the document which shows a bad print/export.
- PDF: Attach the exported PDF and a screenshot of the exact area affected in
the PDF.

Conter examples:

"something wrong with the "kerning" between words" -> Where exatcly in the
export. Add a screenshot demonstrating the missing kerning.

(apart from the currently discussed kerning problems...)

Compared 3.1 and CWS otf01 with the document (prueba_griego.odt) of the
submitter and the Minion Pro font installed on Windows Vista.
- 3.1: font not embedded in the PDF and fallback to "Reprise Rehearsal" font instead
- CWS otf01: Minion Pro is embedded and is displayed as in Writer.

I would consider this issue as verified.

Created attachment 64280 [details]
sample of faulty PDF export in OOo 3.2.0 Build 9418

@es

ok. here we go:

• OS 10.5.8 (intel Mac)

• a random selection of OpenType fonts from different manufacturers:
– ITC Barcelona Std 
– Berthold Formata Pro 
– Adobe Jenson Pro 
– Linotype Avenir Std 
– Monotype Gill Sans Pro

• Only the PDF-export is affected.
Generating a PDF through the Apple OS print dialogue works fine though. But that worked fine in 
previous versions  of  OOo too.

And here is the attachment:
http://www.openoffice.org/nonav/issues/showattachment.cgi/64280/sample.zip

> [...] in the Mac version [...] DEV300m55 [...] nothing is fixed

Please see #desc86 to learn where to get the test version.

Please see http://wiki.services.openoffice.org/wiki/ChildWorkSpace to understand
that such a test version means step 15 of the issue handling process. Only when
this test phase is over there will be a chance that the feature will ever get
into a released development milestone (step 21) such as DEV300_mXX. And if we're
lucky then CWS otf01 may get there in time for OOo 3.2.

@HDU: please confirm that the not yet confirmed "kerning problem" might be an
other follow up issue and that I can set this one to VERIFIED based on my
findings in #desc96.

Thank you!

Created attachment 64283 [details]
Example that works under Ubuntu 9.04

Created attachment 64284 [details]
Example that works under Ubuntu 9.04

Testing 3 fonts used by foniq under Ubuntu 9.04 I had no problems on screen nor
printing a PDF.
Fonts used:
– Adobe Jenson Pro 
– Linotype Avenir Std 
– Monotype Gill Sans Pro
I'm attaching pdf, odt and png files.
http://www.openoffice.org/nonav/issues/showattachment.cgi/64283/ejemplo.zip
Sorry double posting the attachment.

On Mac OS X 10.5.8, with the test build
OOo_3.2.0_090820_MacOSXIntel_install.dmg, I can generate a PDF that subsets the
OTF-CFF fonts, and it appears that their ligatures are preserved.  However, full
justification appears to be disabled or faulty, not only with the OTF fonts, but
any font (tested OTF/CFF, TrueType, and Type1.)  Also, certain Type1 fonts
(e.g., "Olympian") are output in the PDF as garbage (see attachment).

Created attachment 64285 [details]
Screenshot illustrating errors in full justification and certain Type1 fonts, with test build from 8/20/2009

OK, scratch that, make that *any* Type1 font I try gets turned into garbage in
the exported PDF file.  The "DIN-Medium" in the screenshot was actually
TrueType, sorry about that.  Trying other Type1 fonts ("Frutiger 57 Condensed",
"Legacy Sans") resulted in the same garbage as with "Olympian".

@oikoi, you said:
"*full justification* appears to be disabled or faulty, *not only with the OTF
fonts*"

So it obviously has nothing to do with the current issue!

-> write an other issue for this!

> [...] kerning problem [...]

Using the provided sample document I didn't see any problem in the test version that was new 
compared to the related development milestone. Maybe something like issue 92746 or 78815 are 
meant here?

> [...] problems with Type1 fonts [...]

Using the provided sample document I didn't see any problem in the test version that was that was new 
compared to the related development milestone. Please let's focus on the new feature of PS-OTF 
support for printing and PDF-export and any eventual regressions that might have introduced.

Sorry: but the mentioned problems with Kerning and Spacing are not related to 
the use of OpenType Fonts.
We uses allways OpenType I was simply not aware off this problem.
I did some tests with standard Windows fonts as Arial and found out that
the OO-PDFexport simply ignorges some OO-Kerning and OO-SpaceWidth settings. As 
far I can see, the "Font" Width follows the OO-percentages but the spaces stays 
at 100%.
PLease tell me if this is a known issue (Windows)   

Sorry again :-)
Kerning and Space-condencing-expanding works fine only Character spacing is a 
problem
Make a PDF from my Spacing_problem.odt to see wath happens

Sorry again :-)
Kerning and Space-condencing-expanding works fine only Character spacing is a 
problem
Make a PDF from my Spacing_problem.odt to see wath happens

Created attachment 64297 [details]
Make a PDF to see the spacing problems

Created attachment 64298 [details]
Make a PDF to see the spacing problems

> Font Width follows the OO-percentages but the spaces stays at 100%

That's probably either issue 89129 or 104212, which seem to happen independently of PS-OTF or PS-
TTF. I'm not sure if I already mentioned it but please let's focus on issues specific to the PS-OTF-support 
and the test-build...

Verified in CWS otf01.

Tested PDF export and printing on Solaris, Windows, MAC and Linux.

Verified in Win XP - congratulations!

Tested with Iwona, TeXGyre fonts, Yanone Kaffeesatz and other open-sourcers.

If this test release seems fine to others, any idea when this might make it into
a Dev build?

Thanks.

otf fonts in arabic/urdu fonts using otf features are still not beeing exported
to pdf correctly with the oo otf1 version. tested it with the already posted
document here for this issue and for the issue 104011 on Windows XP.

@hussnain: Cannot confirm.
On vista, I installed the Urdu fonts mentioned in issue 104011 and made again an
export to PDF from your document:
- The Urdu fonts are embedded in the PDF
- the PDF "looks good" (so far I don't understand the text and cannot judge
about its quality).

So obviously this you don't have the problem fixed by the current issue and
issue 104011 has been assumed erroneously to be a duplicate of this one.

Feel free to reopen issue 104011 but please detail there *exactly* what and
where the problem is: "still not beeing exported to pdf correctly" or "are
broken and not readable" are to general description.
Describe which characters are broken and if possible and a screenshot of how
they should look like.

@jurf: login there...

http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fotf01

and watch the field "Milestone (integrated)" from time to time.

Might be m57 or m58.

The PS-OTF kerning issue persists in OOO320m8 (OOo 3.2.0-rc1) in Linux; see also
Issue #107739.  Updated attachments follow.

Created attachment 66695 [details]
I prepared a Writer document using different fonts to see which kern correctly and which don't.

Created attachment 66697 [details]
The document converted to PDF using OOo PDF export. Take a look at the lines set in Myriad Pro, Gill Sans MT Pro and Adobe Garamond Premier Pro (all OTF w/ Type1 outlines).

Created attachment 66698 [details]
Here, for comparison purposes, I substituted Gill Sans MT Pro and Garamond Premier Pro with TTF versions I converted from the OTFs used in the 1st PDF myself (would've done the same w/ the Myriad Pro, but that is more complicated due to font locations).

*** Issue 107759 has been marked as a duplicate of this issue. ***

Congratulations, this very useful feature is really neccessary!

But I've done a simple test and I'm still missing some characters. Copy text out
of the PDF is correct, and space for missing characters is calculated correct,
but maybee some glyhpes aren't exportet in PDF.

I will attach an example.

Created attachment 66754 [details]
Missing i und ä in exported PDF.

See followup issue 107831 for support of the deprecated SEAC operator in PS-OTF Type2 charstrings. 
Some PS-OTFs still used this obsolete operator for some of their accented characters because they were 
converted 1:1 from their Type1 ancestors. If there are some important fonts that have not been converted 
to use valid and non-deprecated charstring operators then adding support for this ancient and very 
limited "feature" will be considered.

*** Issue 37991 has been marked as a duplicate of this issue. ***

Hi all,

Did this CWS finally get integrated or not ? From the EIS link posted here
already, it appears that it did not because it was assigned to 3.2, but
should've been assigned to 3.3 or 3.4.

Anyone care to comment as to where it is now, and whether it finally got
integrated or not ? Otherwise, if it isn't integrated, the fix isn't much use to
anyone is it ?

TIA,

Alex