Created attachment 1523 [details]
Original BulletTest.sxw document, created in OOo 1.0.0

Created attachment 1524 [details]
BulletTest.doc, exported from OOo 1.0.0 to Word 97/2000/XP format

Created attachment 1525 [details]
Screen shot of BulletTest.doc from Win98SE/Word 2000 (9.0.2720) showing bullets as "Outline Numbered" instead of "Bulleted"

JA->MRU: reassigned to you...

Hi Caolan,
didn't you work on a similar problem a few days ago? 
I could't find the double Issue/Bug? Do you remember what went on?

I guess that the problem here is something along the lines that the
starsymbol font is missing on the windows machine and that a
substitute has been found by word that has different symbols :-(. (The
starsymbol font is difficult, private code points cause nothing but
trouble)

cmc->cbell: Please can you check to see if that is the case. In word 
open your example document and go to...
tools->options->compatability-> and click Font substitution

Does it say "no font substitution is necessary" or does it say that
some other font has been substituted for starsymbol ?

If I'm right then, then what you should be able to do as a user to
work around this problem is in writer for the numbered paragaphs use
numbering/bullets and go to options and there select character and
change the font away from starsymbol to a font that will exist on any
windows machine, i.e. symbol. That should avoid the problem. 

If this is the problem then the correct long term solution for us is
to accept that other machines will not have starsymbol installed and
to try and bundle starsymbol in the exported word documents i.e.
implement cunning idea in issue 2192. Or to try and convert the
starsymbol characters to symbol/wingdings characters. Of course your
document works fine for me (and probably the testers) because everyone
has word installed on machines that also have writer installed, so
we've all got starsymbol installed :-(

For what its worth the bulleting being exported as outline numbering
is meant to happen, in writer you will see that that pbullet style has
10 levels and each level has more indent that the last level, so it
has to be exported as an outline numbered list to export the
differences between levels.

retitled

I'll assume that my analysis is correct pending any new evidence to
invalidate that view, and so contend that for a full solution we need
to be able to make our exported word documents contain the starsymbol
font to allow word to find a font which has the correct symbols at the
unicode private code points that starsymbol (ab)uses.

*** This issue has been marked as a duplicate of 2192 ***

I checked Tools->Options->Compatability->Font substitution 
and "WingDings" is being substituted for "StarSymbol". I looked 
in /OOo_install_dir/share/fonts/truetype, and the only font is 
opens___.ttf, aka "OpenSymbol", which seems not to have the required 
glyphs.

Is StarSymbol just hidden somewhere, or is it built into the binary 
or something?

I'll try your suggested workaround and let you know.

Thanks!

The workaround seems to work, however it seems like the bullet font
selection needs to be done for each bulleted list. I can change it for
one list, and the next bulleted list created reverts to the original
font. I've also played with font substitution on the OOo side, but it
doesn't seem to make any difference.

Is there an easier way to do this, or could it be scripted somehow?

Thanks!

I have the same problem.

Its just a bad habit of mine to call it StarSymbol, its OpenSymbol
when the application is OOo. 

Sadly the problem with font substitution is that it only makes sense
when there is a substitute font with the same glyph in the same
location. This is the case for fonts that have a true encoding. But
the OpenSymbol font, while a unicode font, makes use of private area
glyphs, i.e. locations which are up to the whims of any given font to
contain random glyphs, or normally none at all. So there is no font
which can be substituted for OpenSymbol correctly when the private
area characters are used. The issue this is duped with might resolve this.

Anyhow, for the workaround to be more pleasant to live with, try
creating a numbering style and do the manual change to symbol
workaround for each list level in it, and use that style from then
onwards. i.e. F11, click the fifth icon that look like number. Right
click a style, e.g. numbering 1 and either create a new style based on
that, or change it. Apply the starsymbol->symbol changes. (note that
what should happen on importing an word document that has lists, is
that a pile of WW list styles are created, the bulleted varients of
which should all be viewable correctly when reexported to word, as
they will have their fonts set to a commonly available windows font,
it can be possible for the reverse problem to exist under linux if
wingdings is not available for example)

Leave the handy stylelist open, when you want numbering to be added to
a paragraph, put the cursor in the paragraph and double click in the
stylelist on your new list style. 

You can fiddle with templates and so on to make the new or modified
styles part of your default template, but that's well outside the
scope of this bug.

I have experimented with styles and various fonts in bullet options,
but I still have the problem with it transforming into outline
numbering in Word.  Furthermore, there is no indent in Word where the
bullet is against the first letter.  If the line manages to wrap, the
second line has text that goes under the bullet rather than flush with
an indent.  The Word filter did a good job with columns and tables,
but bullets are another story.

1) Please, there is nothing inherently wrong with lists being exported
as outline numbering, read back through the bug for my previous
comment on that.

2) There *are* differences in the indentation which are the bane of my
life, especially first line indent models between word and writer.
Generally a one line list should import reasonably well, and export
not so great. There are a number of different sub issues with the list
model, i.e. 

2.1 word seperates numbering from text generally with a tab this is
addressed in issue 3232, and is suprisingly complicated. We do it with
width and spacing attributes, word does it with a great big ugly tab
character and tab atributes attached to the paragraph that is being
indented, very tricky to map them together, for import I need to be
able to have fields contain tabs at the end. Read issue 3232 for all
the fun details.

2.2 There is also as you have discovered a fundamental different of
opinion as to what properties and layout options exist for controlling
what happens when the paragraph properties flow over onto a second
line. The good news is that it's not too common to run into the snag,
the bad news is that some thought needs to go into what should happen.

There is a bit of a mess in word with lists and tabs and indentation
which makes them an ungodly affair to import/export.

But these are independant problems from each other, and not related to
this bulleting issue. Do feel free to discuss these more general
issues in the users@sw or dev@sw mailing lists. Or to submit seperate
issues for seperate parts of the list puzzle that you run into. For
instance some comprehensive word test documents that demonstrate all
possibilites of combinations of list indent vs para indent, with
positive and negative hanging indent and different tab stops would
help flush out the right thing to do for 2.2

For this issue, does changing the font for the bullets and numbering
in writer to wingdings/symbol mean that the bullet itself looks
correct when viewed in word ?

I'm going to look into the comments here and see if I can get it
working. Just some things I noticed.

When composing on linux and exporting to Word, then opening with word,
the bullets appear as a number 10 in a black circle, which would be
explained by the list level thing. 

When I composed on OO for windows (using 2000), I noticed that the
bullet displayed immediately as the 10, before I even exported it. 

I'll give the font substitution a try.

The workaround seems to work....however a more permanent solution is
better.....even if it was just allowing the change in the font used
for bullets to be saved in a configuration file.

I don't particularly like solution to adding a new numbering style
that has the bullets...it seems a little complicated to have to run
for any number of users that will need this change.

Thanks for the workaround though.

Splitting from font embedding proposal.

Going to solve this without using font embedding.

*** This issue has been marked as a duplicate of 3839 ***

Closing, works in SRX643 for me. Track issue 3839 for QA