Issue 5991 - Overline for text in word processor
Overline for text in word processor
Product: Writer
Classification: Application
Component: formatting
OOo 1.0.0
All All
: P3 trivial with 29 votes (vote)
: ---
Assigned To: stefan.baltzer
: oooqa, rfe_eval_ok, usability
: 17031 28247 40452 47809 (view as issue list)
Depends on:
  Show dependency treegraph
Reported: 2002-06-20 01:31 UTC by tsudhonimh
Modified: 2013-08-07 14:43 UTC (History)
10 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation on: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description tsudhonimh 2002-06-20 01:31:45 UTC
In technical writing, words like RESET or ENABLE are overlined at times. Most 
word processing programs are not capable of this: FrameMaker, Interleaf and some 
other expensive publishing programs are the exceptions. 

Could this feature be added to the character formats, under FONT effects, for 
the word processsing and drawing components?  I checked the help files and it's 
not an option now. 

It is in the Math component, but inserting a formula in the dozens of places 
in a chip datasheet where RESET has to be overlined, and making it all line up 
neatly, isn't easy.
Comment 1 stefan.baltzer 2002-11-25 14:25:21 UTC
I could imagine an underline/strikethrough "above the text" or an
emphasis mark "bar".

General comment: Writer is for word processing and so far will
not try to compete with "expencive publishing programs". There will
always be software that can do "magic" compared to a word processing
software (I.e. CAD software...).

Reassigned to Christian.
Comment 2 christian.jansen 2003-03-24 07:55:01 UTC
Reassiged to Bettina.
Comment 3 acli 2004-01-18 09:44:05 UTC
Note that in Chinese the straight "underline" is not text decoration or font
effect; it is a full-fledged punctuation mark. This could be translated as the
"proper name mark" and is roughly equivalent to capitalization in English, but
only used for proper names. It is seldom used nowadays, but is still being
taught and in a certain extent used.

In right-to-left (vertical) mode, in some countries, the usual convention is to
place the proper name mark on the *right* of the proper name. In OOo, this
corresponds to an "overline". Thus, one can argue that overline is needed to
support Chinese more fully.

This might be taken into consideration when evaluating whether to support
Comment 4 acli 2004-01-18 22:02:23 UTC
(Correction: "in some countries" in my previous comment should read "when
following certain older conventions". I still stand by my reasoning; IMHO
allowing  the proper name mark and citation mark ("wavy underline") to be placed
on either side of a piece of text is similar to allowing ruby to be placed on
either side.)
Comment 5 michaelkraemer 2004-04-02 14:22:59 UTC
I strongly support your proposal. I need that feature all the time for
electronics related texts. It would also be a good argument for my colleagues
who still use WinWord to change to OO.

As a rather ugly alternative to the overline, one can put a slash in front of
the word (e.g. /ENABLE, /RESET, /RD, /WR), but other than WinWord, OO doesn't
keep the slash and the word together at the end of line, i.e. the / remains at
the end of the previous line, while the word moves to the next line. That is
probably a philosophical issue, but I would pretty much like the slash to remain
at the beginning of the word.
Comment 6 dodongo 2004-08-04 05:07:48 UTC
To add to the scope of the utility of adding this feature:

I've just started my MA degree in sign language linguistics.  With a reputation
as somewhat of a computer geek, I was asked to set up one computer in our lab
with Linux (the others are Windows or MacOS).  We're using it as a sort of
proof-of-concept machine, to evaluate if Linux provides us with any benefits.

Unfortunately, one absolutely critical
there-is-no-other-convention-for-doing-this ability we have to have in even the
most basic sign language transcriptions is overline text.  AbiWord does support
this feature, so we're probably going to end up using that for the time being,
though OOO is overall such an attractive product it was definitely our first
choice.  The disappointing part is that we just can't use OO in the lab until
this feature is added.

In defense of adding this feature, I don't think we're talking about a fancy,
difficult-to-implement desktop publishing-like situation here.  I don't know
much of software engineering, and I've not had any programming classes (thought
I start this month!), so I can't speak with authority as to the difficulty of
getting this set up.  I understand why it's not been high on the priority list,
but it pains me to realize something as simple as this is preventing another
group from adopting this software.  To the developers, that should be nothing
less than flattering!

Can't we at least nick the code in AbiWord that does this?   :)

In any event, I wanted to a) offer my services however they may be useful; I dig
this project and want to support it however I can, and b) give an example of
another (admittedly teeny-tiny portion of the population) group that would find
this feature absolutely necessary for adoption of OO.
Comment 7 tobiasegg 2004-08-17 15:14:29 UTC
It's an issue with mathematical texts as well. It is no way a feature for luxury
publishing products, but it is a basic need-it-to-get-my-work-done-feature.
Substition by embeded formulas is often less comfortable. 
Comment 8 tobiasegg 2004-08-17 15:20:18 UTC
It's also an issue with writing periodic decimals in main text as stated in Bug
23764 for the formula editor.
Comment 9 lumbercartel 2004-09-03 04:37:11 UTC
This isn't a "magic" feature, it's a standard text-font convention for a number
of common documentation types: logic, finite mathematics, electronic
specifications, etc.

An example: JEDEC's Software Tools Committee would adopt OO.o as our standard
document format for editable specifications in a heartbeat if we could just flag
active-low signals properly.  That's a lot of seats at IBM, Intel, AMD, TI,
Philips, ....
Comment 10 guido.pinkernell 2004-09-04 08:52:04 UTC
*** Issue 17031 has been marked as a duplicate of this issue. ***
Comment 11 wjmurray 2004-11-05 10:25:28 UTC
Can I just add that in high energy physics, where the overline denotes
antiparticle, this is probably the biggest single difficulty with 'alternative'
software, and would give a real advantage to OpenOffice 
Comment 12 lohmaier 2004-11-05 20:05:31 UTC
You can use a combing overline (unicode character U+0305) (or U+0304 combining
macron) provided that you have a font installed that provides this character -
like Doulos SIL, Gentium, Arial Unicode, Lucida Sans Unicode,...

Maybe IssueZilla can handle these:
m̄acron (there should be the macron above the "m") and 
oÌ…verline (line above the "o") now the real words (may result in  garbage): RÌ…EÌ…SÌ…EÌ…TÌ…

You can create an autotext for easy insertion. (you can use autoTexts to insert
the formatted formula as well)

Yet another workaround is to draw a line and put it above the words (set anchor
to character, posistion relative to character). Again use an autoText. This way
you don't have to do the changes over and over again.

All these methods are meant as workarounds. If only a fixed set of expressions
is concerned, they work very good. If the overline is to be put above different
characters, only the first method (combined overline) is useful (but may not
work because a capable font is needed).

keywords & reassigning according to new RFE-process.
Comment 13 lohmaier 2005-01-13 21:43:21 UTC
*** Issue 40452 has been marked as a duplicate of this issue. ***
Comment 14 lumbercartel 2005-05-19 22:03:21 UTC
One workaround that JEDEC has used is to create font sets with overbar.  Still
ugly, but a font selection is probably better than drawing or whatever.

I think I'll have my CS-student son look into doing this one as a summer
project, though ...
Comment 15 lohmaier 2006-03-25 21:36:34 UTC
*** Issue 47809 has been marked as a duplicate of this issue. ***
Comment 16 mike_hall 2006-06-27 07:29:59 UTC
Discovered by chance that Unicode fonts can do this simply by combining a
standard character with a 'Combining Diacritical Mark' and choosing the
overline. Some fonts, like Lucida Sans Unicode don't work too well (the overline
has spaces in it). IPA fonts seem to be better, for example Gentium is an
excellent font and a free download. It's a slow process, but a possible workaround?

[added cc]
Comment 17 kjohnstn 2006-07-29 20:07:19 UTC
I've been following a thread on this issue on the users maillist. Many people
have suggested many possible workarounds, but in my mind they *all* ought to be
considered *workarounds*, not solutions. So I'm adding my votes for this
enhancement: An Overline font effect that spans (that is, does not skip) spaces
and punctuation in a selected string.
Comment 18 mmcg 2007-01-27 02:58:45 UTC
Another 2 votes for this issue.  As another EE, I find the lack of this feature

I've tried the unicode macron approach and it doesn't look good.  The 'insert
formula' approach looked promising after changin the formula font, but it's not
suitable for me.  Formulae are inserted as objects, and as I autogenerate a lot
of documents, this overcomplicates things for my scripts.

I'm willing to take this issue on, if I get some guidance.

As I see it, and I admit to not having hacked on OpenOffice before, the
following would need to be done:

* Add overlining capabilities to the text renderer.  The chances are that this
already exists somewhere as formulae can be overlined. (Do formualae and
ordinary text use the same code? If not, maybe I can borrow from the formula
renderer.  Or maybe copy and modify the underlining code.)

* Update the OpenOffice document XML spec to accept 'overline' as a valid
text-decoration.  Make sure overlined text can be loaded and saved.

* Update the GUI to allow overlining.

* Update documentation/help text.

As I've said - if anyone can point me in the right direction, I'm willing to
give this a shot.

Comment 19 lisif 2007-01-30 23:19:39 UTC
I added 2 votes. Overlines were also extensively used to express abbreviations
in most (if not all) Western European languages before the modern era. In many
disciplines (e.g., philology) reporting these abbreviations as they appear in
the original source (i.e., with overlines) is necessary.

While using unicode overbars is a workaround, it requires to set a different
character size for the letter to be overlined and the overbar itself (if they're
the same size, the overbar "disappears" in the body of most capital letters),
which causes problems when changing the size (or style) of sections of text.
Also, an overbar needs to be added for every single character to be overlined,
which may be very annoying if extensive overlining is needed.
Comment 20 stp 2007-02-04 09:24:37 UTC
In order to get an overline feature it must be available in the file format
also. AFAICT overlining is not yet part of the OpenDocument specification. Thus,
I recommend you also suggest it to the OpenDocument Technical Committee Write a mail to
Comment 21 lisif 2007-02-04 11:12:44 UTC
OpenDocument supports overline (inherited from SVG)
This is the schema (v1.0)
search for "overline", it's just after underline and strikethrough.
Comment 22 martinwhitaker 2007-02-27 00:03:23 UTC
I too would like to see this feature implemented, and am prepared to do the
work. There needs to be some agreement on how it should be done. I can think of
three options:

1) Change "Format->Character->Font Effects->Underlining" to
"Underlining/Overlining" and add extra choices in the drop-down list for various
overline styles. Note that this would not allow text to be both overlined and

2) Add an extra choice, "Line" to the drop-down list "Format->Character->Font
Effects->Emphasis mark". Note that this drop-down list is currently only visible
if support for Asian languages has been enabled, also it would appear that
emphasis marks are not placed over white space (although they are placed over

3) Add a new drop-down list, "Format->Character->Font Effects->Overlining" with
the same options as for underlining. This gives the most flexibility.

Option 1 is the easiest to implement (I've already done it!) and requires
minimal changes to the code base. The code for rendering the overlines is
already present (although a bit buggy).

Option 2 is probably almost as easy to implement and again would not require
major changes to the code base.

Option 3 is fairly straightfoward - you just need to duplicate all the
underlining control - but does mean extensive changes to the code base.

Personally I think option 3 is the one to go for - the others are not really
intuitive to the user.

Some other issues:

1) The current overlining code tends to draw outside the character box when
rendering on screen. This results in a single pixel height line being left
behind when overlined text is moved or deleted. This would need to be fixed.

2) I don't know whether or not the ODF SVG overline attributes can be used for
this purpose. They seem to relate to a font face, not a text style.
Comment 23 tobiasegg 2007-02-27 06:24:22 UTC
I'd vote for option 3 - it's the most flexible of all and might even offer stuff
like double-overline. 

And thanks a lot for doing the work!
Comment 24 tsudhonimh 2008-03-28 03:03:45 UTC
It's been almost 6 years since I requested this feature, a font characteristic
that is used in several fields from linguistics to engineering.

None of the work-arounds really work.
Comment 25 wjmurray 2008-03-28 11:23:00 UTC
Yes, it is a shame. This would be very useful.
Comment 26 martinwhitaker 2008-03-29 16:01:36 UTC
Well, I did do much of the work to implement this feature. I had it working in
Writer and mostly working in Impress. Two things blocked further progress:

1) We need a way to save the overline attribute in ODF files. I submitted a
proposal to the mailing list last May, which
engendered some discussion but got no further. I've just posted a reminder to
the list, but it might help if other voices were heard...

2) We need a formal specification for the changes to OOo. I just haven't had
time to write one. Unlike patching code, which I can do in odd hours here and
there, writing a good specification requires a period of concentrated effort. If
anyone wants to volunteer to do this task, that might speed things along. I
suggest reading before
stepping forward, though.
Comment 27 stefan.baltzer 2008-05-23 10:48:52 UTC
SBA: A quote from
Enhancement is an improvement to an existing feature.
Feature is an addition to the software to add a piece of functionality that does
not yet exist.

This will also require adjustments in the UI.
=> Changed issue type to "Feature".
Comment 28 stefan.baltzer 2008-05-26 12:17:34 UTC
Set Target to OOo 3.1.
Reassigned to Martinwhitaker. He already started working on this.
Comment 29 stefan.baltzer 2008-05-26 12:19:17 UTC
Set to "Started" ( Martin asked so because he has not the rights to set issue
targets and states yet).
Comment 30 martinwhitaker 2008-05-26 18:09:53 UTC
A draft specification is available, see:

The prototype implementation is done.

The sticking point remains getting support for this feature in ODF.
Comment 31 2008-06-26 12:20:20 UTC
@thb: the mtfrenderer probably needs to be extended for this too...
Comment 32 2008-06-26 13:38:48 UTC
OOps, I just saw that the mtfrenderer is already taken care of. Thank you martinwhitaker. Anyway, adding 
thb and me to CC was a good idea.
Comment 33 martinwhitaker 2008-10-30 21:06:54 UTC
Update - the OASIS ODF TC has approved the proposal to support this feature. The
necessary support will be included in ODF 1.2.
Comment 34 Mathias_Bauer 2008-11-05 12:16:13 UTC
Martin, this is great!
So what do we need to do to get that into 3.1 and how can I help you?
Comment 35 marknewlyn 2008-11-06 06:21:34 UTC
Finally! :-D
Comment 36 martinwhitaker 2008-11-09 21:55:52 UTC
Mathias, thanks for offering to help. As far as I am concerned, the work is
basically done, and just needs to get pushed through the approval process. My
patches are in the CWS 'overline3' and Frank M. has promised to review them.

I expect we will need to create a fresh CWS to get back in sync with the
development head - past experience suggests that automatically resyncing the CWS
will result in a big mess (that is why we are already at 'overline3' :-( ). But
I would rather not go through that again until we are close to integration.

Also, there is some renaming I would like to do, to reflect the fact that the
FontUnderline enumeration is now used for both underline and overline
attributes. There is an open issue in the specification relating to this. I
would like to hear other opinions on this, as it affects both the UNO API and
the internal code. Again though, I would prefer not to do this work until we are
close to integration, as it will change lots of lines of code - making resyncing
even more painful.
Comment 37 frank.meies 2008-11-25 09:57:54 UTC
@fl: Could you please take care of the specification upload and feature mail?
After this, please assign this issue to sba, thank you.
Comment 38 rene 2008-11-25 10:00:48 UTC
*** Issue 28247 has been marked as a duplicate of this issue. ***
Comment 39 frank.loehmann 2008-11-25 10:20:56 UTC
The specification can be found here: 
Comment 40 frank.loehmann 2008-11-25 10:22:48 UTC
Ready for QA.
Comment 41 frank.meies 2008-12-15 15:06:38 UTC
Comment 42 stefan.baltzer 2008-12-16 11:19:45 UTC
Verified in CWS overline3.
Test case specification here:
This is implemented in optional AutoTest "w_formatcharacter.bas"
Comment 43 2009-01-30 16:49:58 UTC
Verified in DEV300_m40, .deb version - closing - Sophie