MRU->US: Pls. have a look.

I further investigated the issue and I believe it needs to be redirected to VCL.

How to reproduce -updated :)

1. Open writer
2. Change default font into 'Palatino LinoType'
3. Type 'fff' or 'ttt'
4. Go to the first column by pushing 'Home' key.
5. Pushing right arrow key twice.
6. Get wrong caret position.

To update a caret position by arrow key, SwCrsrShell::UpdateCrsr() finally calls
SwFntObj::GetTextSize(). And this function utilize pKernArray and pScrArray from
OutputDevice::GetTextArray() to calculate the next cursor position.

Interestingly enough, OutputDevice::GetTextArray() returns wrong array - the
last element of the array is 0 - when there is 'ff' or 'tt' before the new caret
position.

---

long OutputDevice::GetTextArray( const String& rStr, long* pDXAry,
                                 xub_StrLen nIndex, xub_StrLen nLen ) const
{
    ...
    // do layout
    SalLayout* pSalLayout = ImplLayout( rStr, nIndex, nLen );

###  During layout, GetCharacterPlacementW() returns DX array which has less
item then mnGlyphCount. ###

    if( !pSalLayout )
        return 0;

    long nWidth = pSalLayout->FillDXArray( pDXAry );

### So, pDXAry has garbage at [mnCharCount -1]. ###

    ...
}

SimpleWinLayout::LayoutText(...)
{
    ...
        nRC = ::GetCharacterPlacementW( mhDC, pBidiStr, mnGlyphCount,
            0, &aGCPW, nGcpOption );
        mnGlyphCount = aGCPW.lpGlyphs ? aGCPW.nGlyphs : aGCPW.nMaxFit;
    ...
}

given the amount of research on this issue, I think it's time to set it form
unconfirmed to new.
I don't reassign since I'm not sure which project contains vcl - I think its gsl
but I'm not sure...

I think you are correct.
The vcl *module* is part of gsl *project*.

Sorry for confusion. :)

@cloph: the amount of research time spent on an issue isn't the point.

The idea behind the 'Unconfirmed' flag is to protect the very limited resources
of OO.o developers from having lot's of invalid bugs assigned to them no one can
reproduce.
Hence a task that changed from 'Unconfirmed' to 'New' has to be clearly
reproducible, including a bugdoc and a screenshot.

So can anyone pls. tell me what this bug is about. 
Are we talking of caret movement, which is the tiny little flag added to the
text cursor, which points to the currently active text direction in an BiDi
context/document?
And according to this issue, this shall be font dependant; at least there is a
defect with Palatino Linotype, right?
I still can not imagine nor reproduce the failure.
Can anyone pls. describe in detail. Thx.

Created attachment 16780 [details]
Wrong cursor movement with Palatino Linotype font under Windows XP

Hi us,

I attached screenshot and hope it helps you to understand the issue clearly.
Also, I tested the issue again with newer version of OO.o under Windows 2K/XP.

                                       OO.o 1.1.2  OO.o 1.9.m47
-------------------------------------+------------+------------+
Windows 2K (Palatino LinoType v1.15) | no problem | no problem |
Windows XP (Palatino LinoType v1.40) |   problem  |   problem  |
-------------------------------------+------------+------------+

As you mentioned, the font seems to have a defect, specifically in v 1.40, with
'f' and 't'. I believe this causes the width of the string calculated
incorrectly during the cursor movement. So, we can simply say this is a defect
of the font. :-)

However, there was no problem while I was inputting the characters. This
probably means that writer could calculate the width of the string correctly
even using the font. It thus appears to me there is a room for improving cursor
movement.

By the way, calc and impress shows similar behavior with the font. So, it would
be better to change the component into gsl __if this is determined as issue of
OO.o__.  

-Jeongkyu

@us
>the amount of research time spent on an issue isn't the point.

Sorry, I thought that since jeongkyu already tracked it down to a specific part
of the code and thus should have enough info.
My criteria was not the time spent on this issue, but providing a piece of
source code that is "guilty" of the issue. The descrition seemed clear to me as
well.
Sorry again.

I began experiencing this problem after XP SP2 upgrade. The text becomes garbled
too. My solution is to use Palatino instead of Palatino Linotype.

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

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

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

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

US-HDU: you volunteered for this one, don't you?

Darn, it looks like even for non-CTL text the OpenType features of the font is
triggered since SP2. With automatic ligatures the mnCharCount==mnGlyphCount
assumption in SimpleWinLayout is no longer true...

.

Created attachment 18747 [details]
Automatic Ligatures on some systems cause metrics problems

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

Turned of automatic ligatures in CWS usp4all.

reopening for reassignment

reassigning

HDU->SBA: please verify in CWS usp4all
Testing hints: 
- also have a look at the scenarios in the duplicate issues
- watch out for negative performance impacts of the fix (e.g. when texts contain
ff,ffi,fl,tt, etc.)
- also check with other fonts with similar problems to Palatino (like Brioso*,
Sylfaen, FineHand, Barbedor, Pigiarniq, Uqammaq)

HDU->SBA: should the issue be cloned with an OOo1.1 target too?

SBA:  I toyed with the other fonts and some docs of the duplicate issues as
well. No findings -> Verified in CWS usp4all.

SBA: I cloned this issue in order to have it fixed in OO o 1.1.5 too. See issue
37404.

Note that fix under 1.9.m69, applies only to text display, whereas print remains
garbled. Problem should be solved together.

For what it's worth, ligatures still cause problems in OpenType fonts with
PostScript outlines, such as the versions of Myriad and Minion included with
Acrobat Reader 7.

I've filed a bug on this, Bug 39482, with a temporary kludge to fix it, but
there has to be some better fix than just turning on Windows' compatibility mode.

Well, what about the printing? Are there plans to fix it?

This wrong caret movement problem also occur with OOo 1.1.1 and 1.1.4 (Japanese)
under Windows XP (Japanese). The attached document is written in french. Weirdly
it seems the caret madness happens mainly with the « fi » letter pair. For
example if you place your cursor on the line « Suite à la perte d'un chèque,
j'ai pris contact avec vous cet après-midi afin d'enregistrer ma » and move it
from left to right pressing the right arrow key, the caret madness happens at «
afin », between the f and i. But the problem also occurs with other words so
it's not specific to the « fi » pair.

Note that this problem is always and only reproducible on japanese versions of
OOo (versions 1.1.1 and 1.1.4, since we upgraded) under Windows XP. I have no
problem with my english OOo 1.1.4 under Windows 2000 (english).

Last but not least I solved the problem by changing the fonts used by the
different styles of the document. Once I changed the font to Arial or Tahoma,
the caret madness didn't happen anymore. So I guess this problem is specific to
the Palatino Linotype font.

Created attachment 22648 [details]
French text document using the Palatino Linotype font

boardquake > goa

As been posted on these fora before, Palatino Linotype causes erratic behaviour
under XP.
The problem is that the issue is reported as fixed under 1.1.5 and 2.0, when in
fact priniting still causes problems.
Apparently the people involved are currently too busy to reply, so we better
just wait.

@boardquake,goa:
if there are still errors with 'Palatino Linotype' on XP this time while
printing I suggest to file a follow-up issue. 
As this one states: "When I use 'Palatino Linotype' font in the document, I
experienced wrong caret movement with arrow key." 
This issue is in state Fixed/Verified. Pls. understand that bug handling renders
impossible especially when trying to address different probs in the same issue
after fixing and verification of the original problem.

SBA: OK in 680m78. Closed.

Note: As US said, the caret/cursor movement was adressed with this one. 
I just confirmed issue 42863 ("Ligatures problems with font "Palatino Linotype"
when printing") that can be considered the follow-up issue.

> SBA: OK in 680m78. Closed.

I disagree. "Using 'Palatino Linotype' font causes wrong caret movement" was a
very restrictive description of the problem, but the comments show it was much
more complex:

------- Additional comments from hdu Tue Oct 26 02:45:24 -0800 2004 -------
Darn, it looks like even for non-CTL text the OpenType features of the font is
triggered since SP2. With automatic ligatures the mnCharCount==mnGlyphCount
assumption in SimpleWinLayout is no longer true...


1. The problem was not only with Palatino Linotype but with *thousands* of
OpenType fonts having a (liga) feature for Latin script (I have written a fairly
complete list of these fonts here: <http://cgm.cs.mcgill.ca/~luc/linard.html>)

2. The problem is triggered by a new version of Uniscribe (usp10.dll), which
brings support of the (liga) feature for Latin script, i.e. the versions
included in:
- Windows XP SP2
- Windows 2003 SP1
- Windows Longhorn

3. It wasn't only a "wrong caret movement" problem, but, as hdu said:

------- Additional comments from hdu Fri Oct 29 01:23:25 -0800 2004 -------
Automatic Ligatures on some systems cause *metrics problems*


The issue 27336 will more appropriately be named "Metrics problems with OpenType
fonts on recent Windows versions".

And the metrics problems are solved for OpenType fonts with TrueType outlines
only on screen, not in print. For OpenType fonts with CFF (PostScript) outlines,
it works neither on screen nor in print. Look at the message from hdu, November 4:

 ------- Additional comments from hdu Thu Nov 4 08:05:15 -0800 2004 -------
HDU->SBA: please verify in CWS usp4all
- also check with other fonts with similar problems to Palatino (like Brioso*,


Adobe Brioso Pro is an OpenType CFF font, did you make the test?

If you don't have Brioso anymore, install Adobe Reader 7, take the OpenType
fonts (*.otf) in C:\ProgramFiles\Adobe\Acrobat 7.0\Resource\Font\ and copy them
in C:\Windows\Fonts. You can then test Adobe Minion Pro and Adobe Myriad Pro,
and see that the problem is still here.

Finally!
You hit the nail on the head.
There are multiple issues filed around this problem. Perhaps you should reopen
this one?