Issue 59997

Created attachment 32872 [details]
bullets in relevent area of opensymbol font

Created attachment 32874 [details]
result

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

cmc->mmeeks: fyi, for the love I know you have for OpenSymbol

Created attachment 32895 [details]
how about this bullet instead

what about adding that symbol to opensymbol instead?

U+e572 is a bad choice since it is from the private use area of the font. This
breaks compatibility (think of exporting to HTML, exporting to doc, etc. The
target-machine won't have opensymbol installed, but there is a bigger chance
that the user has a font with the bullets from the regular area. (Arial, Times
New Roman, Courier New, ... all have the U+25cb bullet.

Apart from that: U+e572 is not part of OpenSymbol either (none of the fonts I
have installed has a bullet there) - so this would break vanilla OOo instead of
fixing it. 

MRU->FL: should the OpenSymbol font be enhanced or should we take different
default characters for 2nd, 5th and 8th bullet level?

So - Radek has been working on this and has extended our custom symbol font -
based on re-arranging the existing OpenSymbol glyphs.

It's at the normal place Caolan:

http://go-oo.org/ooo-build/fonts/

Of course - Sun has traditionally fiercly resisted improving opens___.ttf, and
without the trivial fixes / re-arrangements we provide in our version (available
under the JCA etc.) all manner of other bullets are broken out of the box.

It would be *really* nice if Sun would re-consider incorporating our changes:

2006-01-04  Radek Doulik  <rodo@novell.com>

	* fonts/OpenSymbol.sfd: added circle glyph to fix
	https://bugzilla.novell.com/show_bug.cgi?id=141377. generated new
	opens___.ttf using fontforge tool.

IH: I think we should really consider using Radek's version of the font if it is
better than the currently used one. 
I also think that this should/could be fixed for 2.0.2 and not in 3.0. 
It is important that this font works in OOo and we have/had so much trouble with
this in the past and now and I would be very glad to have a working version of
the font and I appreciate any kind of help with those issues here.
Radek, what is about the other existing bugs we have in OpenSymbol (e.g. 54450
and 54182 or the incompatibility with some Win Systems), do you have fixes for
this in your version? Do you have an idea how to add proper hinting information
to OpenSymbol (unfortunately FontForge does not support this feature of adding
truetype hinting to fonts)? Thanks...

HDU->QA reminder: Please also test the deadly combination of (Win98) + (symbol
font) + (unicode symbols) extensively. Also see issue 45163 (where we had to
patch FontForge to get Win98 happy).

> IH: I think we should really consider using Radek's version of the font
> if it is better than the currently used one. 

That's great news - it sucks to have to have this in ooo-build; I'd love to
remove it from our build.

> It is important that this font works in OOo and we have/had so much
> trouble with this in the past and now and I would be very glad to have
> a working version of the font and I appreciate any kind of help with
> those issues here.

Nice.

> Radek, what is about the other existing bugs we have in OpenSymbol
> (e.g. 54450 and 54182 or the incompatibility with some Win Systems),
> do you have fixes for this in your version ?

Well - what ours fixes [ and I did much of the historic work here ] is big
chunks of wingdings, webdings etc. that are missing equivalents in the positions
specified in vcl's font mapping tables. ie. before we added glyphs at these
locations we simply got '[]' (square box missing-glyph symbols) :-)

Some good examples would be the 2 bullet tests at:

http://go-oo.org/ooo-build/test/draw/

of course - a better way is to use =char(A1) in a spreadsheet & map out the
columns for the various fonts. I did that in the past but can't find the test
sheet for some reason.

Wrt. breaking Win32 functionality - I guess that's unlikely AFAICS there is no
code that checks whether a glyph is available in opens___.ttf and if not falls
back to something more useful - but I may be mistaken.

And of course Win32 machines all have the fonts - so the effects are seen mostly
only on Linux machines.

HTH.

IH: what about copyrigth issues if there are characters/symbols of wingdings and
webdings in the font? Does anyone here have a proper knowledge what is
allowed/not allowed in this specific field?

> Wrt. breaking Win32 functionality - I guess that's unlikely AFAICS

As a counter example I'd like to point to the high priority issue 45163 and
issue 40717. Also it is not a good idea to rely on fallback mechanisms. So the
point I'm trying to make is: Test the new OpenSymbol font so extensively that it
doesn't  cause regressions.

> Wrt. breaking Win32 functionality - I guess that's unlikely AFAICS

As a counter example I'd like to point to the high priority issue 45163 and
issue 40717. Also it is not a good idea to rely on fallback mechanisms. So the
point I'm trying to make is: Test and fix the new OpenSymbol font so extensively
that it doesn't  cause regressions.

Unfortunatelly I don't have win98/MS Office here. I will attach the modified
font so that someone with win98/MS Office can test it.

Changes I made to out opens___.ttf:
  * added circle glyph
  * synced characters [names] with upstream opens___.ttf so that it has all the
character the upstream version have.

I will also attach output of sfddiff of these too.

I used this version of fontforge (I am not sure whether it already contains your
patch):

rodo@aquarius:~/cvs/ooo-build/build/src680-m145> fontforge --version Copyright
(c) 2000-2005 by George Williams.
 Executable based on sources from 13:45 3-Aug-2005.
fontforge 20050803

Created attachment 32928 [details]
output of sfddiff updated_font upstream_font

Created attachment 32929 [details]
updated font

> IH: what about copyrigth issues if there are characters/symbols of
> wingdings and webdings in the font?

There are not :-) clearly copying glyphs from propriatory fonts would be gross
infringement. We havn't done that - instead, the primary task is just
cut/paste/resize/flip etc. of the existing opens___.ttf glyphs to the correct
positions by consulting the vcl font mapping tables.

In addition - we created a small number of new glyphs - (some really simple ones
- > >> that sort of thing - that required little effort).

All our work in the font is covered by the JCA - so, AFAICS there should be no
issue.

FL: I made some investigations why we have not seen this OOo issue before
integrating this change for 2.0.1.

The spec. (see section 2.0.2):
http://specs.openoffice.org/writer/numbering/NumberingBullet1_PP1.sxw shows the
symbols formatted in OpenSymbol, but is seems that Writer did make an internal
font substitution due to the missing 0x25CB symbol in OpenSymbol. I will double
check this with help from our Writer development tomorrow. Personally I have no
problem to use the changed OpenSymbol font even for StarOffice, because the
0x25CB symbol in the  StarSymbol font looks pretty ugly due to its bigger size.
I will discuss this with our font expert tomorrow. Furthermore OpenSymbol could
be extended and adjusted and we are not allowed to change StarSymbol on our own
due to it's license.
I propose to fix this issue for 2.0.2.

I would like to point out that as of today the CVS version of FontForge no
longer triggers the OpenSymbol on Windows problems mentioned above. The idea
from the patch in issue 45163 was commited there. So anyone doing artwork in
OpenSymbol is advised to use at least a CVS-2006-01-06 version.

Created attachment 32953 [details]
new updated font generated with fonforge build from today cvs sources

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

IH: I have installed Radek's latest version of the font on WIN XP and MAC OS X.
It works fine in OOo on both platforms, but Windows System Utilitiy character
map tool does not like the font - it just shows empty fields, this kind of
behaviour was in the past also a good hint for problems with the font on Win98.
Radek's font is based on our 1.7 Version - so we also need to try to incorporate
our later fixes into this version. 
I have also seen that some symbols occur more than once in the font. Radek, is
this becauso of mapping issues or is it just a mistake? Thanks...

FL: I have just tested the OpenSymbol font on my Windows system, and I had
problems in accessing it in the Insert-Special Characters dialog of my
StarOffice 8. StarOffice 7 and the system viewer from Windows worked fine. Any
ideas?
I think the bullets, especially for level 1 and 2, should be of the same size
and same positioning. The current bullets do not achieve these points. The
StarSymbol font has the same issue and I think this does not look good.

IH->FL: I can not reproduce FL's problem on my WinXP system. Insert->Special
Character of OpenSymbol works fine in SO8 and OOo2.0. It looks like a Font-ID
problem. FL, did you remove the StarSymbol font and what other Symbol fonts do
you have on your system. What is about OpenSymbol in other Apps on your System -
are there also problems?

FL: Problem in SO8 solved after restart incl. quick starter. SO7 and other apps
did not need a restart.

>IH: I have also seen that some symbols occur more than once in the font.
> Radek, is this becauso of mapping issues or is it just a mistake? Thanks...

That is correct - this is deliberate, since similiar looking (but non-identical)
glyphs occur across lots of Win32 fonts - eg. a round '*' bullet glyph; in
opens___.ttf we tend to just copy the glyph around to the places where it should
be - and not change it, since the differences are small for these glyphs between
fonts.

> I think the bullets, especially for level 1 and 2, should be of the same size
> and same positioning. The current bullets do not achieve these points. The
> StarSymbol font has the same issue and I think this does not look good.

I am playing with it now. I have made level 1 and 2 equal size. I have also
changed version to 1.10 and updated copyright to 2006.

BTW, as fontforge doesn't produce good hints intruction for ttf I am thinking
about using PS type 1 font. How does this sound?

So far I was unable to make OOo use type1 font, but other applications were able
to use it and it looks way better for small sizes (as default bullet size here
for example)

Any idea why my OOo doesn't see/use the type1 font?

> I am thinking about using PS type 1 font. How does this sound?

Veto!

Here are some reasons:
Type1 fonts are not native on some platforms for OOo like Win95/98/ME/NT.
Sometimes additional software must be installed.

Truetype is more unicode friendly and easier to subset.
Type1 is limited to 255 characters.
...

> Type1 fonts are not native on some platforms for OOo like Win95/98/ME/NT.
> Sometimes additional software must be installed.

With fontforge we can generate both formats and package type1 for unix distros
and ttf for win systems. (with single .pfb source)

> Truetype is more unicode friendly and easier to subset.
> Type1 is limited to 255 characters.

I didn't look into specs, but the font I generated and used here contains 1000+
characters and works OK in other apps with better looking output.

apart from the "bullets should have same position and size", the new font
unfortunately still increases the line-spacing way too much.

Please apply the settings I mentioned in issue 54450 to fix this problem. It
would be unfortunate if that one would not be fixed when a major QA regarding
OpenSymbol is sheduled/needed anyway...

* Choose 
     Elements|Font-Information
         Tab OS/2
             Tab Metrics
* In the box "Win Ascent Offset"   enter "-630" (old value "0")
* In the box "Wind Descent Offset" enter "-200" (old value "0")
  leave the other settings unchanged.

radekdoulik: a type1 font can contain more than 256 glyphs, but the contained
encoding vector can only contain 256 entries. This problem is usually
circumnavigated by using different encoding vectors (e.g. you have multiple
lines in the Xserver's fonts.dir files for the same font), but this method
somewhat fails for symbol fonts.

IH: it is getting so quiet here. Could the QA and UE people please decide how we
will / have to proceed here? As I already mentioned my suggestion is to take
Radek's font and add our changes from 1.7->1.9 into this one. 

if "Radek's font" is the attached one, please modify it to fix the linespacing
problem as directed earlier before integrating it.

I do not know how your opensymbol font dependencies work for bullet display, but
wouldn't it be easier to add a "change bullet" button in the gui that becomes
active after a character is selected for format-bullets and
numbering-bullets(tab) that would allow the user to define the character and
size of the bullet (or make it a right click option for the default character or
all eight and or all levels) that would seem to solve the issues in about a
dozen posts I have read and eliminate the need to force opensymbol to be used
here. then the user defines the character and size and they can do with it as
they please. This is my one pet peave with open office. I can not define my
default bullet and have the program store the character info. It seems the
programming approach is to use a single font instead of making the character
user defined.

You could create a template with your preferred numbering/bullets as soon as
issue 56252 is fixed.

Created attachment 34703 [details]
latest font with unified size of level 1 and 2 item bullets

Created attachment 34707 [details]
source file to previous .ttf font

Created attachment 34708 [details]
one more font with linespacing fixed

Created attachment 34709 [details]
source file to previous .ttf font

I have attached new font with linespacing and level 1,2 bullet sizes fixed. Let
me know if anything else is needed.

cmc->fl: So can we standardize on this font as the opensymbol font, and retarget
for 2.0.3 ? 

I fixed one more problem today, attaching new fonts. I changed the encoding to
match the original upstream version of opens___.ttf and fixed problem with
minussign glyph which had set unicode value to 0x00ad instead of 0x2212.

Created attachment 34803 [details]
updated version

Created attachment 34805 [details]
updated version

IH: I have tested Radek's latest Version on WinXP and Mac OS X. The font works
very good and even in Windows character map tool it looks ok (that is a good
hint for compatibility with Win98, but this has to be tested explicitely,
unfortunately I haven't got  Win98). Good work, Radek. Thanks a lot.

IH->Radek: We had some issues with OpenSymbol in the past because we could not
include TrueType Hinting into the font. The issues were about some symbols (e.g.
- or =) disappearing at specific zoom rates or point sizes. I fixed this in the
other branch of the font by changing the font outline itself (I made some of the
thin lines thicker). Do you have an idea how we will try to avoid such problems
in your version of the font? Do we or you have any chance to put TrueType
Hinting into the font or do you have any other idea or suggestion to fix this?

IH->ALL: We still need QA and UserExp. approvement for setting this task to
2.0.3. Any news?

 

fontforge doesn't provide good truetype font hinting. I am not sure at what time
Michael branched the font, but it might contain the changes you did I guess. If
you remember the problematic glyphs, it is possible to find out which glyphs
differ from original.

Created attachment 35133 [details]
sfddiff output for original and new font

IH->Radek: I never had any chances to save the truetype hinting instructions in
a font in fontforge, neither good or bad ;-)
I think the important chars we should look at are: - (minus) + (plus) and = (equal)
I will also have a look at your diff file.
 

IH: I just have tested the latest font in OOo's Formula Editor: plus, minus and
equal chars look good but I have seen a problem with some brackets and some
other symbols; their upper part is some kind of cut away. Can someone else
confirm this?

Created attachment 35137 [details]
Screenshot of my formula editor problem

FL: Here are my results after I did some investigation with help of the Writer team.

Original problem of current issue: Character 0x25CB not found in OpenSymbol.

This would be fixed by this issue. Maybe some regressions in Math or with other
symbols due to font problems with the changed OpenSymbol font. 

Related problems not addressed today :
1. Sizes of bullets are to big (especially #2, #5, #8)
2. Sizes of bullets are not relative to font used in paragraph due to assigned
“Bullet†character style)
3. Bullets (especially #2, #5, #8) do not look very good (fixed for OOo with
this current issue, but still valid for SO due to use of different font)

Other aspects:
- old document must not change when loaded in newer version of OOo

Discussed solutions:
1. Change sized of the characters in the OpenSymbol / StarSymbol font to get rid
of the “Bullet†character style ->  has been rejected
2.  Change size attribute in “Bullet†character style from 9 to 8 or 7 pt ->
does not solve problem #2 and #3.
3. Change size using hard coded size calculation -> high effort, maybe probs
with old documents but would solve #1-2
4. Use new set of symbols -> would fix #1-3 if there are better ones in
StarSymbol and OpenSymbol. But why we hadn't used those from the very beginning?

Root cause analysis: 
We have defined wrong bullet characters in specification. Input on these
characters used came from development. Nobody ever challenged the symbols used
in the spec. Then change did not made it into OOo 2.0 final, because change got
lost on integration in master (two times). Then integrated for PP1 too shortly
before release of OOo 2.0.1, so problem had been overlooked. Furthermore
StarSymbol font is present on all systems used @Sun, so OpenSymbol font didn't
get used on in-house testing, even if OOo version was tested.

Solution
The solution of entire problem is very easy and i63395 handles this needed
change. We need to use exactly the same bullets used after importing a Microsoft
Word document. The font substitutionof OOo will handle systems where those fonts
are not present. Then the round trip experience is good and even problem #3 will
get fixed.

Unfortunately this means that the changed OpenSymbol font of this issue will
only be used when loading old OOo 2.0.0 - 2.0.1 documents. But nevertheless we
need the current fix for OOo 2.0.3. to fix the missing character in those cases.

IH->FL: Why is the changed font only used for 2.0 and 2.0.1 docs? Which font is
used for the other ones in OOo? It can only by OpenSymbol but why not also the
changed version? I do not understand this. 
Which fix do you mean by we need this fix? Nethertheless I think we should
switch to Radek's new version of the font because it is better than all other
OpenSymbol Versions - regardless what this means for our bullet problem. 
It does not look like that we can fix this whole bullet problem thing before
3.0, because for this we need a completely new font for SO and OOo with TrueType
Hinting and so on... 

FL: OOo will use different characters as soon if 63395 get fixed. Then we will
use Courier New, Symbol and Windings. If not present on the system, our font
substitution determines a replacement (this is already working, see attached WW
doc on Linux). If we will discover further issues, we still could use their
equivalents from StarSymbol and OpenSymbol and could shift the fix to OOo 2.0.4.

Radek's font will be integrated to OOo 2.0.3 that's why I have changed the
target to OOo 2.0.3.

Created attachment 35139 [details]
Word standard bullet demo document

Radek -> IH: I am unable to reproduce the formula problem here. Please could you
attach a document with the formula?

Created attachment 35178 [details]
File for the Formula Problem

IH->Radek: I have attached the problematic formula, but I think the problem will
always occur when brackets or something like that are used. My platform is WinXP
without font smoothing and the zoom rate was set to 100%. 

IH->FL: If we use Courier New, Symbol or Windings as replacement fonts, what
will happen on Linux? 

FL: Unfortunately my submission from Friday did not made it into this issue. So
I give it a second try.

FL->IH: The OOo font replacement will handle this. If we discover issues, we can
change to other characters/fonts as well.

FL->Radek: I have changed the owner to you, because you are in charge of the font.

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

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

What remains to be done here ? - and Radek: lets get doing it :-)

IH: We have to open issues here: My formula editor problem and Win98
compatibility has not been checked by now. Can anyone else also reproduce the
problems with the font in the formula editor?

I have tested the formula editor on Linux and it works OK.

IH, could you please test earlier versions of the font on windows (the one which
don't have metric changes/linespacing fix suggested by cloph)?

IH->Radek: Ah, this was a good hint - formula problem must have something to do
with the line spacing metrics - I tested it with the font from Jan, the 5th and
it worked fine - anyone any ideas?

IH->cloph: It looks like we have a problem here with your new values for "Win
Ascent Offset" and "Win Descent Offset". You said in #54450# that your values
did not affect the placement of the brackets and other symbols. Did you test
this on Win oder Linux? We have a problem on Win here. Does anyone know about
the different handling of those values on Win and Linux? 

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

@ih 
I myself did tests on linux, - I asked members of the german community to check
on windows and they reported that there were no bad sideeffects in fomrulas either.
Will ask them to check with the font from this issue again.

Maybe the newly added symbols have other metrics that influence the "base for
the offset" (i.e. either one would have to use non-offset values or adapt these
values to match the current set of symbols).

In any case I would like to have the linespacing symbol resolved before
replacing opensymbol.

had a look at radek's font.
It has other additional settings in the metrics tabs compared to the original
font (i.e. "Typo Ascent Offset" is set to 2118 (original: 0) "Typo Descent
Offset" is set to 70 (original: 0) and "HHead Descent Offset" is set to 0
(original : 471))

I'm pretty sure that this is the cause for the broken display on windows.

I don't know why the other values have been changed. If there was a reason to do
so, then the offset values have to be changed...

IH: There is indeed a problem with the Line Spacing of the latest OpenSymbol
font. If you type normal text in Writer and apply Numbering/Bullets formatting
to this area you get a distance inbetween the different lines of text, but line
spacing is set to single line. This only happens with this version of
OpenSymbol. If you install older OpenSymbol or StarSymbol fonts everything is ok. 

IH: I have read the TrueType Font Spec regarding to WinAsc, WinDes, TypoAsc,
TypoDes and Asc and Des in the hhea area. I have used different values for this
in Fontforge and created the font, but I think Fontforge does something wrong
there: my final font never containted the values I have put in the dialog in
FontForge. I get the best results if I set all of those fields to Zero
(standard). If I do this I have no formula problem and no line spacing problem
in Writer. But I am not sure what we should do because of #54450#  ?

IH: I did some investigation in the internet and people there say that it
depends on the application which metric values are used. So as we now know (from
HDU's comment in #54450) that our Office uses the OS2 table I think it is the
best idea to set the metrics in the OS2 table to the same values as in the other
metrics tables in the font.

IH: I have created a font with TypoAsc and WinAsc set to 1638 and TypoDes and
WinDes set to 410 (not as offset values) - these values are the same as in the
general tab. I get good results for the line spacing in Writer and Formula
Editor. I will attach my version so someone else can confirm this.

Created attachment 35654 [details]
New Version of OpenSymbol with metrics set to 1638,410

I want to remind everyone, that there already a lot of documents for which at
least part of the layout depends on OpenSymbol/StarSymbol. E.g. enumerations may
be affected when the line height of these fonts changes. Because of this the
guys from the Writer team should carefully monitor this issue, so I CCed them.

replace CC member 'od' by 'fme'

IH: This is a very good remark of HDU. I think we really should not do any
experiments with the metrics here. I would rather do it like in my latest test
version and set all metrics for Ascend and Descend to the same values in all
areas without changing them to completely new ones, somewhere.

IH: So do you use same values as in old upstream opens___.ttf? Could you please
also attach the .sfd file so that I can update ooo-build with it?

Radek, I did unfortunately not use your .sdf as a basis for my testfont. Please
use your font and create a new version with TypoAsc and WinAsc set to 1638 and
TypoDes and
WinDes set to 410 (not as offset values). According to HDU we should take those
"old" values for the font not to crash the metrics of existing docs.

Created attachment 35683 [details]
updated font with asc 1638 dsc 410 (not as offset)

Created attachment 35684 [details]
source of updated font

IH, Tor: I have updated the font with these "old" values. Please check if it
works OK on windows.

The newly attached font shows the linespacing bug on linux again.

As to compatibility argument:

The linespacing-bug by itself is a compatibility bug (between linux and windows)
Thus fixing it will change the look of old & new documents on linux, but it will
fix the display only. It will not have impact on formulas, but only on normal
text where symbols are taken from opensymbol.

So I absolutely disagree that we should not experiment with the metrics - the
opposite is the case. We should get them straight. Now is the time to fix them,
since this one will replace the font and require big QA anyway.

Not fixing this problem is like saying: "Documents on linux will not look the
same on windows - we know that and we won't fix that"

Remember that the "linebreak in justified paragraphs" behaviour was changed,
modifying the look of old documents by naming it a bugfix. These kind of changes
have a much bigger impact on compatibility than this one. (I can give you more
examples where compatibility was sacrified/influenced) 

Again I ask why in Radek's font not only the values I mentioned were changed,
but additional ones. (see my comment from Tue Apr 11 07:21:22 -0700)

Created attachment 35690 [details]
another font with metrics required by cloph

cloph: I have created another version with your metrics, so others can test it.

To answer your question, I changed only the values you suggested. Previous
versions of the font already had the other values set. (as you can check from
previous attachements)

BTW, could you explain why do you want different asc/dsc for Win and Typo
fields? Fonforge description is a little unclear on what these fields do. It
says that usually Win asc/dsc fields are used for the line spacing on Win, so in
this case it doesn't matter what is set in Typo fields. (but the description
might be wrong) Anyone know how is it then?

And how did you get/calculated these values?

> cloph: I have created another version with your metrics, so others can test it.

Thanks. Looks good on linux (i.e. linespacing problem solved and no other
problems with formulas)

> To answer your question, I changed only the values you suggested. Previous
> versions of the font already had the other values set. (as you can check from
> previous attachements)

I did not compare the settings to the ones attached to this issue, but to the
ones currently shipped with OOo/the one in cvs (md5sum
dd604fd024ebb8efc7872e2f5dd4b927)
The very first one attached to the issue has all metrics set to zero btw.
(already different to the one in cvs), the second one marked with "created with
fontforge" has the Typo-values set, so is already different from the first one
and from the one in cvs..

> BTW, could you explain why do you want different asc/dsc for Win and Typo
> fields?

There is no specific reason. I determined the values by trial and error and the
Win-Values made the difference... 
I didn't touch those that did not make a difference on linux. And in the
"original" version, the Typo values are set to zero.

As http://fontforge.sourceforge.net/editexample5.html#baseline reads the
Typo-Values are used on windows, that's why I didn't touch them and want to have
them reset to the values from cvs that are known to work. They may need some
minor finetuning, but values of 2000+ offset just seem wrong to me. (and
apparently caused problems) It also writes that Windows-programs often don't
care and take the win-values instead (and since simonAW tested the values on
windows and said they were OK I still think they'll don't cause the
display-problem in the attached formula-doc)
In http://fontforge.sourceforge.net/fontinfo.html#TTF-Metrics it already reads:
"The Typographic Ascent and Typographic Descent are /supposed/ to represent the
line spacing of the font on the windows platform. Sadly very few applications
actually use them (most applications use the Windows Ascent/Descent described
above)."

> And how did you get/calculated these values?

I did not calculate them. They were determined by modifying the value,
installing the font, launching OOo, test whether the effect still is visible,
modify it again, ....

> In http://fontforge.sourceforge.net/fontinfo.html#TTF-Metrics it already reads:
> "The Typographic Ascent and Typographic Descent are /supposed/ to represent the
> line spacing of the font on the windows platform. Sadly very few applications
> actually use them (most applications use the Windows Ascent/Descent described
> above)."

Yeah, and that seems to be the source of this problem. The font worked OK on
windows before win asc/dsc changed, so I guess the latest attached font will
have the same problems on windows again.

I would prefer if we use the font with original metrics as suggested by hdu.
That way we will fix the bug this issue was open for. Let solve the other
problems in different issues later. Trying to solve more problems at once seems
to get us nothing (so far).

Reassign to hdu, re-target because it is too late for 2.0.3.

I have created new bug for the linespacing issue.

HDU, IH: could we get the font with original metrics upstream and finally close
this long issue? ;-)

the linespacing issue: http://qa.openoffice.org/issues/show_bug.cgi?id=65855

IH: good idea, radek. please create a CWS and check in your font that fixes this
bug here and then we can take care of the other (line spacing) problem.

OK, cws created (sorry for delay). It is named opensymbol01 and contains the
fixed font and the font source.

Not sure how to proceed now, how do I ask for QA to start?

marking FIXED as it landed in the cws

IH: not sure whether you want to fix the linespacing problem in that cws or
later in other. I would like to set cws status to "ready for QA", is that OK
with you?

IH->Radek: it is ok for me - fix this step by step and do the linespacing issue
in another one - so you can set this cws to ready for qa - please set the
QA-Representative for this cws to mru and send this bug to mru for testing.
Thank you, Radek for your good work.

IH->Radek: I've talked to mru from our QA and this is also ok for him. He we
also take care that this cws gets the right release target flag for 2.0.4.

 

Retargeted to next release due to resource limitations.

IH: It is really no good news that Radek's fix will not make it into 2.0.4. I am
very disappointed - this has always been postponed since 2.0.2

Targetting issue to newly introduced "OOo 2.1".

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

I have now tested this font extensively on Win and Unix platforms and in my eyes
it looks VERY good!!!
Maybe somewhone can pst somewhere a message, tat a new version could be
downloaded from this issue.
Thanks for the good work on it, Radek!

In the version "Apr 13 12:37:00" the upper part of the characters is missing,
not only in OOo but also in WordPad. (Win XP Home SP2)

I cannot share Regina's notice. I tested on Win98/2000/XP, Linux and Solaris.
The font from mentioned date looks good (no missing characters in the top part).
Maybe you could attach a screenshot of the "Insert/Special character" dialog
with the part displaying wrongly on your system?

Created attachment 38939 [details]
Screenshot from OOobuild9062; WinXp desktop 1024x768 Pixel;Groß 120DPI; Clear Type

Screenshot of textdocument attached, insert special dialog will follow.
The version "Apr 13 08:37:00" is OK for me.

Created attachment 38940 [details]
sreenshot of insert special character dialog

regina, which font do you use? There were 2 fonts added on Apr 13th.

The right one should be:

Thu Apr 13 08:37:00 -0700 2006: opens___.ttf 	updated font with asc 1638 dsc 410
(not as offset) (application/octet-stream)

http://www.openoffice.org/nonav/issues/showattachment.cgi/35683/opens___.ttf

OKie, you answered when I was still typing the question :)

Yeah, the "morning" version is the right one.

this can be closed now for 2.1, right ?

Yeah, checked it in 680m188 OOo build. CLosing issue.