Re: [Libreoffice] [Libreoffice-ux-advise] Styles cleanup removing option page std fonts
On Thu, Oct 20, 2011 at 12:41:36PM +0200, Astron wrote: Hi. On the whole, I like your plans, but... One of the ideas I think would be great, is having a small LibreOffice logo on the default document somewhere on the lower-right of the page. Or in the default footer. The logo is stylish and non-obtrusive. This sounds like the LibreOffice version of the infamous Sent from my iPhone signature. As such, I think it's a really bad idea /for the default template/. No one needs to be informed so rudely about how you created your document. (Anyone who cares can still include a LibO icon in their documents, of course.) I couldn't agree more. There is colophon for this kind of things for whoever wants to include it. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Reducing duplicating strings
On Mon, Nov 07, 2011 at 10:35:41PM +0100, Lior Kaplan wrote: Hi, One of the things I noticed while working about LibO translation is the strong deja-vu feeling. I keep thinking - wait, I've already translated this string. I went to check the code, and found out there are actually a lot of duplicated strings. In the meantime you can use a more intelligent translation tool, I used to use Virtaal[1], it has a very nicely presented translation UI for translation memory and it is very helpful with duplicated strings even across files (and even if not 100% duplicate). It was a real time saver for me (I used several PO editors trough the years, but Virtaal was the best, I don't do much l10n now). [1] http://translate.sourceforge.net/wiki/virtaal/index Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Fix Kashida justification when there is no Kashida glyph
If the font has no Kashida glyph (or if its width is = 0) no Kashida
gets inserted but the place of Kashida would still be filled with blank
space (intercharacter) which is wrong.
This patch removes the reasonable default value of mnMinKashida which
makes no sense at all; either the font have a Kashida glyph and
mnMinKashida is set to its width or it doesn't and mnMinKashida is kept
0.
This value is then queried in sw and if = 0 then there is no valid
Kashidas (the place of the return is arbitrary chosen by trial and
error; returning earlier in lcl_CheckKashidaPositions either always
disables Kasida justification or does not have any effect at all.)
---
sw/source/core/text/itradj.cxx|4
vcl/generic/glyphs/gcach_ftyp.cxx |1 -
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/sw/source/core/text/itradj.cxx b/sw/source/core/text/itradj.cxx
index 19fb4d1..190cc4a 100644
--- a/sw/source/core/text/itradj.cxx
+++ b/sw/source/core/text/itradj.cxx
@@ -166,6 +166,10 @@ bool lcl_CheckKashidaPositions( SwScriptInfo rSI,
SwTxtSizeInfo rInf, SwTxtIte
xub_StrLen nKashidasInAttr = rSI.KashidaJustify ( 0, 0, nIdx, nNext -
nIdx );
if ( nKashidasInAttr )
{
+// Kashida glyph looks suspicious, skip Kashida justification
+if ( rInf.GetOut()-GetMinKashida() = 0 )
+return false;
+
xub_StrLen nKashidasDropped = 0;
if ( !SwScriptInfo::IsArabicText( rInf.GetTxt(), nIdx, nNext -
nIdx ) )
{
diff --git a/vcl/generic/glyphs/gcach_ftyp.cxx
b/vcl/generic/glyphs/gcach_ftyp.cxx
index 44d8958..49bac49 100644
--- a/vcl/generic/glyphs/gcach_ftyp.cxx
+++ b/vcl/generic/glyphs/gcach_ftyp.cxx
@@ -1099,7 +1099,6 @@ void ServerFont::FetchFontMetric( ImplFontMetricData
rTo, long rFactor ) const
// initialize kashida width
// TODO: what if there are different versions of this glyph available
-rTo.mnMinKashida = rTo.mnAscent / 4; // a reasonable default
const int nKashidaGlyphId = GetRawGlyphIndex( 0x0640 );
if( nKashidaGlyphId )
{
--
1.7.0.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] [PATCH] Fix Kashida justification when there is no Kashida glyph
Hi Thorsten, On Mon, Nov 28, 2011 at 11:57:04AM +0100, Thorsten Behrens wrote: Khaled Hosny wrote: This patch removes the reasonable default value of mnMinKashida which makes no sense at all; either the font have a Kashida glyph and mnMinKashida is set to its width or it doesn't and mnMinKashida is kept 0. Hi Khaled, nice one, pushed - by any chance, do you have a small test document that demonstrates the problem, e.g. with a common font that lacks kashida support? Such that going forward, we don't break this again. It is really an edge case and I don't think there are fonts with Arabic coverage lacking Kashida, however I'm developing a font where I trick LibreOffice not to do Kashida justification by having a zero width Kashida glyphs (The font is pretty complex with many contextual forms and Kashida justification as implemented in LibreOffice, or other application for that matter, is guaranteed to always produce bad result). Anyway, the font can be obtained from here[1], and I'm attaching a test file that shows this issue. [1] https://sourceforge.net/projects/amiri/files/ Regards, Khaled lo_no_kashida.odt Description: application/vnd.oasis.opendocument.text attachment: 3.4.pngattachment: 3.5_patch.png signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Remember the RTL interface
On Tue, Nov 29, 2011 at 11:12:36AM +0100, Matteo Casalin wrote: 2) Mirroring of checkmarks: in decoview there's a strange bug-related comment which says roughly don't mirror checkmarks in RTL, following by code that actually mirrors them. My questions are then: should they be mirrored or not, and what does really appear on an RTL environment? They should not be mirrored, even in handwriting the check mark is drawn the same RTL or not (the only instance I've seen check mark drawn the other direction was by a left-handed person) Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Fix rendering of GTK combobox in RTL
Hi all,
Here is a little patch that fixes a rendering buglet that annoyed me
since ever. Native GTK applications swap the position of the button and
editing area of comboboxes in RTL and themese expect that, but LO does
not.
The same issue happens with spin buttons and other similar widget, I'm
just making sure I'm doing it right before sending other patches.
Also I'm not sure how GTK3 relates to this (is it affected/need to be
fixed separately etc.) since I can't build with it here.
BTW, Application::GetSettings().GetLayoutRTL() is now used in several
places (and may be more will come), would it be more rideable/save a few
microsocends to have a
bool isLayoutRTL = Application::GetSettings().GetLayoutRTL()
(or something like that) on the top of the file?
Regards,
Khaled
From a8fd7c4a5dbf57003339af883ae795eefe093f90 Mon Sep 17 00:00:00 2001
From: Khaled Hosny khaledho...@eglug.org
Date: Wed, 30 Nov 2011 08:57:46 +0200
Subject: [PATCH] gtk: fix RTL combobox rendering
GTK themes expect the button and the editing area to be swapped in RTL.
---
vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx b/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx
index 2cdd032..6afba20 100644
--- a/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx
+++ b/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx
@@ -2185,6 +2185,8 @@ sal_Bool GtkSalGraphics::NWPaintGTKComboBox( GdkDrawable* gdkDrawable,
RectangleaEditBoxRect( pixmapRect );
aEditBoxRect.SetSize( Size( pixmapRect.GetWidth() - buttonRect.GetWidth(), aEditBoxRect.GetHeight() ) );
+if( Application::GetSettings().GetLayoutRTL() )
+aEditBoxRect.SetPos( Point( x + buttonRect.GetWidth() , y ) );
#define ARROW_EXTENT0.7
arrowRect.SetSize( Size( (gint)(MIN_ARROW_SIZE * ARROW_EXTENT),
@@ -2254,8 +2256,11 @@ static Rectangle NWGetComboBoxButtonRect( int nScreen,
if( nPart == PART_BUTTON_DOWN )
{
aButtonRect.SetSize( Size( nButtonWidth, aAreaRect.GetHeight() ) );
-aButtonRect.SetPos( Point( aAreaRect.Left() + aAreaRect.GetWidth() - nButtonWidth,
- aAreaRect.Top() ) );
+if( Application::GetSettings().GetLayoutRTL() )
+aButtonRect.SetPos( Point( aAreaRect.Left(), aAreaRect.Top() ) );
+else
+aButtonRect.SetPos( Point( aAreaRect.Left() + aAreaRect.GetWidth() - nButtonWidth,
+ aAreaRect.Top() ) );
}
else if( nPart == PART_SUB_EDIT )
{
@@ -2271,6 +2276,8 @@ static Rectangle NWGetComboBoxButtonRect( int nScreen,
Point aEditPos = aAreaRect.TopLeft();
aEditPos.X() += adjust_x;
aEditPos.Y() += adjust_y;
+if( Application::GetSettings().GetLayoutRTL() )
+aEditPos.X() += nButtonWidth;
aButtonRect.SetPos( aEditPos );
}
--
1.7.0.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Remember the RTL interface
On Tue, Nov 29, 2011 at 02:18:41AM +0200, Lior Kaplan wrote: Hi Guys, As 3.5.0 enters the first beta (ok, ok - beta0), I'd like to remind you on the RTL stuff from the conference last month. This isn't a mail for what about bug X, just taking the opportunity to send a general reminder... (: Is there a list of those issue somewhere for the mere mortals who did not attend the conference? I'd like to give it a try (when I get bored from drawing letters), may be I can find some really simple stuff to work on :) Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix rendering of GTK combobox in RTL
On Wed, Nov 30, 2011 at 01:12:08PM +, Michael Meeks wrote:
Hi Khaled,
Thanks for your patch ! :-)
On Wed, 2011-11-30 at 09:11 +0200, Khaled Hosny wrote:
Here is a little patch that fixes a rendering buglet that annoyed me
since ever. Native GTK applications swap the position of the button and
editing area of comboboxes in RTL and themese expect that, but LO does
not.
:-)
The same issue happens with spin buttons and other similar widget, I'm
just making sure I'm doing it right before sending other patches.
Sure - it'd be great to have this all fixed up.
Also I'm not sure how GTK3 relates to this (is it affected/need to be
fixed separately etc.) since I can't build with it here.
Sadly it'd be need to be fixed separately, that is one bit of code that
cannot be shared; but gtk3 will be highly experimental for 3.5 so ...
don't worry :-)
OK, someone will have to remember fixing them when GTK3 is the default :)
BTW, Application::GetSettings().GetLayoutRTL() is now used in several
places (and may be more will come), would it be more rideable/save a few
microsocends to have a
Ho hum; that method is a bit distressing, I'd hope that it would cache
the value itself, and get notifications when / if it changes.
bool isLayoutRTL = Application::GetSettings().GetLayoutRTL()
Updating that can be a pain if/as/when the user tweaks it in the
settings; clearly if we can do this at the top of the method, or
(better) accelerate the GetLayoutRTL impl. itself ;-)
Having said that we hsould prolly be using:
inc/vcl/outdev.hxx:sal_BoolIsRTLEnabled() const
{ return mbEnableRTL; }
on the OutputDevice if we have one around to improve efficiency.
That is too complex for me :p so I'll keep doing what seems to work.
On a, not so, different note, I found that setting LibreOffice language
to one different from system language, e.g. LO in Arabic but LANGUAGE is
set to en and vice versa, GTK will be using the directionally of the
system language, so stuff that get reversed in RTL will not, while it is
reversed in LibreOffice resulting in the reverse of the bugs being
fixed. GTK takes the directionally from its translation catalog, so it
seems the gettext domain used by GTK is the one from system language
regardless of the actual LibreOffice language, may be there is a way to
fix this?
Another minor nit; it looks like the combo doesn't join up very
elegantly with the drop-down in some themes [ cf. the attached image ]
when in LTR mode - any thoughts on that ?
No idea, those control are broken in different way in my machine. I'm
attaching two new patches now really fixing compoboxes (in your
screenshot, what I fixed earlier with the one with entry box) and spin
buttons.
This is really a huge improvements in the RTL UI, and case I didn't say
it before, LibreOffice is really the best thing that happened to OOo
since it was leashed upon the world (and I like the name, BTW).
Regards,
Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix rendering of GTK combobox in RTL
Oops, the patches :)
On Fri, Dec 02, 2011 at 11:43:37PM +0200, Khaled Hosny wrote:
On Wed, Nov 30, 2011 at 01:12:08PM +, Michael Meeks wrote:
Hi Khaled,
Thanks for your patch ! :-)
On Wed, 2011-11-30 at 09:11 +0200, Khaled Hosny wrote:
Here is a little patch that fixes a rendering buglet that annoyed me
since ever. Native GTK applications swap the position of the button and
editing area of comboboxes in RTL and themese expect that, but LO does
not.
:-)
The same issue happens with spin buttons and other similar widget, I'm
just making sure I'm doing it right before sending other patches.
Sure - it'd be great to have this all fixed up.
Also I'm not sure how GTK3 relates to this (is it affected/need to be
fixed separately etc.) since I can't build with it here.
Sadly it'd be need to be fixed separately, that is one bit of code that
cannot be shared; but gtk3 will be highly experimental for 3.5 so ...
don't worry :-)
OK, someone will have to remember fixing them when GTK3 is the default :)
BTW, Application::GetSettings().GetLayoutRTL() is now used in several
places (and may be more will come), would it be more rideable/save a few
microsocends to have a
Ho hum; that method is a bit distressing, I'd hope that it would cache
the value itself, and get notifications when / if it changes.
bool isLayoutRTL = Application::GetSettings().GetLayoutRTL()
Updating that can be a pain if/as/when the user tweaks it in the
settings; clearly if we can do this at the top of the method, or
(better) accelerate the GetLayoutRTL impl. itself ;-)
Having said that we hsould prolly be using:
inc/vcl/outdev.hxx:sal_BoolIsRTLEnabled() const
{ return mbEnableRTL; }
on the OutputDevice if we have one around to improve efficiency.
That is too complex for me :p so I'll keep doing what seems to work.
On a, not so, different note, I found that setting LibreOffice language
to one different from system language, e.g. LO in Arabic but LANGUAGE is
set to en and vice versa, GTK will be using the directionally of the
system language, so stuff that get reversed in RTL will not, while it is
reversed in LibreOffice resulting in the reverse of the bugs being
fixed. GTK takes the directionally from its translation catalog, so it
seems the gettext domain used by GTK is the one from system language
regardless of the actual LibreOffice language, may be there is a way to
fix this?
Another minor nit; it looks like the combo doesn't join up very
elegantly with the drop-down in some themes [ cf. the attached image ]
when in LTR mode - any thoughts on that ?
No idea, those control are broken in different way in my machine. I'm
attaching two new patches now really fixing compoboxes (in your
screenshot, what I fixed earlier with the one with entry box) and spin
buttons.
This is really a huge improvements in the RTL UI, and case I didn't say
it before, LibreOffice is really the best thing that happened to OOo
since it was leashed upon the world (and I like the name, BTW).
Regards,
Khaled
From bc3e8081c2b679518735ac4013cedde0c96e9db0 Mon Sep 17 00:00:00 2001
From: Khaled Hosny khaledho...@eglug.org
Date: Fri, 2 Dec 2011 14:10:32 +0200
Subject: [PATCH 1/2] gtk: fix RTL spin button rendering
---
vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx b/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx
index 6afba20..cdd388d 100644
--- a/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx
+++ b/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx
@@ -2026,8 +2026,11 @@ sal_Bool GtkSalGraphics::NWPaintGTKSpinBox( ControlType nType, ControlPart nPart
{
// Draw an edit field for SpinBoxes and ComboBoxes
Rectangle aEditBoxRect( pixmapRect );
-aEditBoxRect.SetSize( Size( upBtnRect.Left() - pixmapRect.Left(), aEditBoxRect.GetHeight() ) );
-aEditBoxRect.setX( 0 );
+aEditBoxRect.SetSize( Size( pixmapRect.GetWidth() - upBtnRect.GetWidth(), aEditBoxRect.GetHeight() ) );
+if( Application::GetSettings().GetLayoutRTL() )
+aEditBoxRect.setX( upBtnRect.GetWidth() );
+else
+aEditBoxRect.setX( 0 );
aEditBoxRect.setY( 0 );
NWPaintOneEditBox( m_nScreen, pixmap, NULL, nType, nPart, aEditBoxRect, nState, aValue, rCaption );
@@ -2080,7 +2083,10 @@ static Rectangle NWGetSpinButtonRect( int nScreen,
buttonSize -= buttonSize % 2 - 1; /* force odd */
buttonRect.SetSize( Size( buttonSize + 2 * gWidgetData[nScreen].gSpinButtonWidget-style-xthickness,
buttonRect.GetHeight() ) );
-buttonRect.setX( aAreaRect.Left() + (aAreaRect.GetWidth() - buttonRect.GetWidth()) );
+if( Application::GetSettings().GetLayoutRTL() )
+buttonRect.setX
Re: [Libreoffice] Tell me Easy Hack 42782 remove a dog ! is a joke !
Hi Julien, On Wed, Dec 14, 2011 at 11:03:15PM -0800, julien2412 wrote: Hello, This morning I'm still angry about this tracker. I read it yesterday and spoke my mind on IRC dev channel. I was glad I wasn't alone to think this easyhack is nonsense. I put a quick comment on this tracker but guys, I'd like to know your opinion about this even it's not a dev subject. Though I can't care less about LibreOffice having a picture of dog or not, I'm really offended by your Islamophobic remarks, so please save us this nonsense. This is a software project, if you have some political, cultural or religious agenda, please take it somewhere else. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Tell me Easy Hack 42782 remove a dog ! is a joke !
On Thu, Dec 15, 2011 at 11:58:52AM +, Michael Meeks wrote: On Thu, 2011-12-15 at 13:14 +0200, Khaled Hosny wrote: I'm really offended by ... This is a software project, if you have some political, cultural or religious agenda, please take it somewhere else. I'm sorry you're offended Khaled; this is (I suspect) a consequence of our growth - that we have a diverse and healthy project: so we can now start the infighting ! :-) May be offended was a strong word, it should read concerned about the attitude, it is a little hypocritical to ask others to respect your culture while you are showing no respect to theirs, after all LibreOffice users are not French immigrants who have to either accept the French ideals or return back to their homes. I'm well aware that many people will not like many of the things that I stand for, and be offended by some of my opinions :-) personally I'd like to hope that I can still air them from time to time, and people will put up with me: IMHO having some secularness and blandness censorship filter of discourse on IRC will only create other channels that people will migrate to. It is not about personal opinion, everyone is free to say whatever he likes, but suggesting that it should be a project policy to accept only culture X values and implying it is inherently superior than culture Y values is no longer a personal opinion. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Tell me Easy Hack 42782 remove a dog ! is a joke !
On Thu, Dec 15, 2011 at 05:05:34AM -0800, julien2412 wrote: I don't know if it's a French ideal, it's just the fact that an image of dog should'nt possibly offend anyone. True, if you consider only one culture, the fact is that the world is vastly different and what can't possibly offend anyone in one culture can be highly offensive in another. LO should not dictate that that a certain culture is superior to others, and if we can remove a possibly offending item to certain people, what harm can be caused by that? Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Remember the RTL interface
On Wed, Dec 14, 2011 at 02:45:27AM +0200, Lior Kaplan wrote: On Wed, Nov 30, 2011 at 9:25 AM, Khaled Hosny khaledho...@eglug.org wrote: On Tue, Nov 29, 2011 at 02:18:41AM +0200, Lior Kaplan wrote: Hi Guys, As 3.5.0 enters the first beta (ok, ok - beta0), I'd like to remind you on the RTL stuff from the conference last month. This isn't a mail for what about bug X, just taking the opportunity to send a general reminder... (: Is there a list of those issue somewhere for the mere mortals who did not attend the conference? I'd like to give it a try (when I get bored from drawing letters), may be I can find some really simple stuff to work on :) The list of bugs I maintain is at http://wiki.hamakor.org.il/index.php/ %D7%A2%D7%91%D7%A8%D7%99%D7%AA_%D7%91%D7%9C%D7%99%D7%91%D7%A8%D7%94_%D7%90%D7%95%D7%A4%D7%99%D7%A1 #.D7.91.D7.90.D7.92.D7.99.D7.9D_.D7.A4.D7.AA.D7.95.D7.97.D7.99.D7.9D While the text is in Hebrew, the bug numbers will help you understand what's going on. I'll try to see how to also maintain a similar list in English. I've seen it already (that is how I reached the RTL bugs I was commenting in recently :) I just created a meta bug for RTL issues (already listed you in CC for it): https://bugs.freedesktop.org/show_bug.cgi?id=43808 Thanks. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Drop XLFD support from fontmanager
XLFD support was removed in commit 269f91c (#i110171) except for parsing
fonts.dir and fonts.alias. I don't think this makes much sense in
fontconfig era, and dropping it simplifies the font manager a bit (I
don't even think we use server fonts at all).
---
vcl/generic/fontmanager/fontconfig.cxx |3 +-
vcl/generic/fontmanager/fontmanager.cxx | 503 +--
vcl/inc/vcl/fontmanager.hxx | 40 +---
3 files changed, 5 insertions(+), 541 deletions(-)
diff --git a/vcl/generic/fontmanager/fontconfig.cxx
b/vcl/generic/fontmanager/fontconfig.cxx
index 90d59f1..eb0e9b6 100644
--- a/vcl/generic/fontmanager/fontconfig.cxx
+++ b/vcl/generic/fontmanager/fontconfig.cxx
@@ -547,10 +547,9 @@ int PrintFontManager::countFontconfigFonts(
boost::unordered_maprtl::OString, i
#endif
// not known, analyze font file to get attributes
// not described by fontconfig (e.g. alias names, PSName)
-std::list OString aDummy;
if (eFormatRes != FcResultMatch)
format = NULL;
-analyzeFontFile( nDirID, aBase, aDummy, aFonts, (const
char*)format );
+analyzeFontFile( nDirID, aBase, aFonts, (const char*)format );
#if OSL_DEBUG_LEVEL 1
if( aFonts.empty() )
fprintf( stderr, Warning: file \%s\ is unusable to
psprint\n, aOrgPath.getStr() );
diff --git a/vcl/generic/fontmanager/fontmanager.cxx
b/vcl/generic/fontmanager/fontmanager.cxx
index 450a9ce..5e20b91 100644
--- a/vcl/generic/fontmanager/fontmanager.cxx
+++ b/vcl/generic/fontmanager/fontmanager.cxx
@@ -133,18 +133,6 @@ inline sal_uInt32 getUInt32BE( const sal_uInt8* pBuffer )
return nRet;
}
-static FontItalic parseItalic( const ByteString rItalic )
-{
-FontItalic eItalic = ITALIC_DONTKNOW;
-if( rItalic.EqualsIgnoreCaseAscii( i ) )
-eItalic = ITALIC_NORMAL;
-else if( rItalic.EqualsIgnoreCaseAscii( o ) )
-eItalic = ITALIC_OBLIQUE;
-else
-eItalic = ITALIC_NONE;
-return eItalic;
-}
-
// -
static FontWeight parseWeight( const ByteString rWeight )
@@ -184,169 +172,6 @@ static FontWeight parseWeight( const ByteString rWeight )
return eWeight;
}
-// -
-
-static FontWidth parseWidth( const ByteString rWidth )
-{
-FontWidth eWidth = WIDTH_DONTKNOW;
-if( rWidth.Equals( bold ) ||
-rWidth.Equals( semiexpanded ) )
-eWidth = WIDTH_SEMI_EXPANDED;
-else if( rWidth.Equals( condensed ) ||
- rWidth.Equals( narrow ) )
-eWidth = WIDTH_CONDENSED;
-else if( rWidth.Equals( double wide ) ||
- rWidth.Equals( extraexpanded ) ||
- rWidth.Equals( ultraexpanded ) )
-eWidth = WIDTH_ULTRA_EXPANDED;
-else if( rWidth.Equals( expanded ) ||
- rWidth.Equals( wide ) )
-eWidth = WIDTH_EXPANDED;
-else if( rWidth.Equals( extracondensed ) )
-eWidth = WIDTH_EXTRA_CONDENSED;
-else if( rWidth.Equals( semicondensed ) )
-eWidth = WIDTH_SEMI_CONDENSED;
-else if( rWidth.Equals( ultracondensed ) )
-eWidth = WIDTH_ULTRA_CONDENSED;
-else
-eWidth = WIDTH_NORMAL;
-
-return eWidth;
-}
-
-// -
-bool PrintFontManager::XLFDEntry::operator(const PrintFontManager::XLFDEntry
rRight) const
-{
-sal_Int32 nCmp = 0;
-if( (nMask MaskFamily) (rRight.nMask MaskFamily) )
-{
-nCmp = rtl_str_compareIgnoreAsciiCase_WithLength(
aFamily.pData-buffer,
-
aFamily.pData-length,
-
rRight.aFamily.pData-buffer,
-
rRight.aFamily.pData-length );
-if( nCmp != 0 )
-return nCmp 0;
-}
-
-if( (nMask MaskFoundry) (rRight.nMask MaskFoundry) )
-{
-nCmp = rtl_str_compareIgnoreAsciiCase_WithLength(
aFoundry.pData-buffer,
-
aFoundry.pData-length,
-
rRight.aFoundry.pData-buffer,
-
rRight.aFoundry.pData-length );
-if( nCmp != 0 )
-return nCmp 0;
-}
-
-if( (nMask MaskItalic) (rRight.nMask MaskItalic) )
-{
-if( eItalic != rRight.eItalic )
-return (int)eItalic (int)rRight.eItalic;
-}
-
-if( (nMask MaskWeight) (rRight.nMask MaskWeight) )
-{
-if( eWeight != rRight.eWeight )
-return (int)eWeight (int)rRight.eWeight;
-}
-
-if( (nMask MaskWidth) (rRight.nMask MaskWidth) )
-{
-if( eWidth != rRight.eWidth )
-return
Re: [Libreoffice] [PATCH] Drop XLFD support from fontmanager
On Fri, Jan 13, 2012 at 01:26:20PM +0200, Tor Lillqvist wrote: I don't even think we use server fonts at all). Funnily enough, we have a type called ServerFont... vcl/inc/generic/glyphcache.hxx , but that name is probably historical, and what it actually means nowadays is the exact opposite;) Yup, I noticed that a while ago, and it confused me for a while :) Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Drop XLFD support from fontmanager
On Fri, Jan 13, 2012 at 01:42:03PM +, Caolán McNamara wrote: On Fri, 2012-01-13 at 13:19 +0200, Khaled Hosny wrote: XLFD support was removed in commit 269f91c (#i110171) except for parsing fonts.dir and fonts.alias. I don't think this makes much sense in fontconfig era, and dropping it simplifies the font manager a bit (I don't even think we use server fonts at all). Excellent, I had noticed recently that we were switching on a supportFontconfig variable to show/hide a bunch of stuff in spadmin to handle installing fonts in a pre-fontconfig X based environment and removed a massive whack of stuff which is never enabled for use off that. I noticed some of that stuff in passing, good to see it gone too. That patch was inspired by your recent cleanup work :) Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Horizontal glyph adjustments are ignored with ICU layout
Hi every one,
This my first message to the list, hopping it will be a fruitful
experience :)
I was trying to debug fdo#31016[1] since it breaks almost all my fonts,
it toke me few months but I think I finally got the root of it (I
started working on it few weeks before libreoffice was announced, what a
nice code base ;).
Anyway, it turned out that the issue is not specific to kerning nor
Arabic, but affects all horizontal glyph positioning in the ICU layout
path; the problem does not show on Windows nor with Graphite fonts and
of course not with con-CTL.
The X adjustment of glyph widths is simply ignored, and glyphs are drawn
stacked after each other baased on their original width, which results in
kerning being ignored as well as other forms of glyph positioning like
cursive anchors, however vertical glyph positions (in the Y access) are
OK.
In source/glyphs/gcach_layout.cxx, ICU's layoutChars() is called and new
glyph indices and positions are returned, which is then fed into
SalLayout in the form of GlyphItem's. Though GlyphItem has maLinearPos
which holds its absolute position, many places in the code re-calculate
glyph position from its mnOrigWidth (original glyph width) and mnNewWidth
(width after adjustments), but the ICU path simply sets mnNewWidth to
mnOrigWidth since ICU layout engine does not return individual glyph
widths, resulting in failure of glyph position re-calculation which
manifests in this bug.
As a prove of concept, the attached patch trays to set mnNewWidth in a
very hackish way by subtracting current glyph position from the of next
non-diacritic (+ve) glyph. It does indeed fix the problem (see the
attached screenshots), but it looks very unreliable to me. May be a
cleaner solution is to re-implement all the broken virtual methods to
eliminate the re-calculation part.
Hope this helps, and sorry for the broken terminology as I'm not really
a developer and less of C++ one (I can only do much of C++ that looks
like C, which I don't really speak either).
[1] https://bugs.freedesktop.org/show_bug.cgi?id=31016
Regards,
Khaled
--
Khaled Hosny
Arabic localiser and member of Arabeyes.org team
Free font developer
diff --git a/vcl/source/glyphs/gcach_layout.cxx b/vcl/source/glyphs/gcach_layout.cxx
index cda8749..7531d2b 100644
--- a/vcl/source/glyphs/gcach_layout.cxx
+++ b/vcl/source/glyphs/gcach_layout.cxx
@@ -534,12 +534,35 @@ bool IcuLayoutEngine::operator()( ServerFontLayout rLayout, ImplLayoutArgs rAr
aNewPos = Point( (int)(pPos-fX+0.5), (int)(pPos-fY+0.5) );
const GlyphMetric rGM = rFont.GetGlyphMetric( nGlyphIndex );
int nGlyphWidth = rGM.GetCharWidth();
+int nNewWidth = nGlyphWidth;
if( nGlyphWidth = 0 )
bDiacritic |= true;
// #i99367# force all diacritics to zero width
// TODO: we need mnOrigWidth/mnLogicWidth/mnNewWidth
-else if( bDiacritic )
-nGlyphWidth = 0;
+else {
+if( bDiacritic ) {
+nGlyphWidth = 0;
+nNewWidth = 0;
+} else {
+// Hack, find next +ve width glyph and calculate current
+// glyph width by substracting the two posituons
+const IcuPosition* pNextPos = pPos+1;
+for ( int j = i + 1; j nRawRunGlyphCount; ++j, ++pNextPos) {
+LEGlyphID nNextGlyphIndex = pIcuGlyphs[j];
+
+if( (nNextGlyphIndex == ICU_MARKED_GLYPH) || (nNextGlyphIndex == ICU_DELETED_GLYPH) )
+continue;
+
+const GlyphMetric rNextGM = rFont.GetGlyphMetric( nNextGlyphIndex );
+int nNextGlyphWidth = rNextGM.GetCharWidth();
+
+if (nNextGlyphWidth0) {
+nNewWidth = pNextPos-fX - pPos-fX;
+break;
+}
+}
+}
+}
// heuristic to detect glyph clusters
bool bInCluster = true;
@@ -593,7 +616,9 @@ bool IcuLayoutEngine::operator()( ServerFontLayout rLayout, ImplLayoutArgs rAr
nGlyphFlags |= GlyphItem::IS_DIACRITIC;
// add resulting glyph item to layout
-const GlyphItem aGI( nCharPos, nGlyphIndex, aNewPos, nGlyphFlags, nGlyphWidth );
+GlyphItem aGI( nCharPos, nGlyphIndex, aNewPos, nGlyphFlags, nGlyphWidth );
+aGI.mnNewWidth = nNewWidth;
+//printf(%ld: %d=%d\n, aGI.mnGlyphIndex, aGI.mnOrigWidth, aGI.mnNewWidth);
rLayout.AppendGlyph( aGI );
++nFilteredRunGlyphCount;
nLastCharPos = nCharPos;
attachment: before.pngattachment: after.png___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Horizontal glyph adjustments are ignored with ICU layout
On Fri, Jan 07, 2011 at 11:25:33PM +0100, Thorsten Behrens wrote: Khaled Hosny wrote: Anyway, it turned out that the issue is not specific to kerning nor Arabic, but affects all horizontal glyph positioning in the ICU layout path; the problem does not show on Windows nor with Graphite fonts and of course not with con-CTL. The X adjustment of glyph widths is simply ignored, and glyphs are drawn stacked after each other baased on their original width, which results in kerning being ignored as well as other forms of glyph positioning like cursive anchors, however vertical glyph positions (in the Y access) are OK. Hi Khaled, wow, many thanks for your detailed analysis - that's actually usually the hardest part for most of the bugs. :) I'll look into this early next week. Great, glade it helps and hop long standing bug will get fixed :) Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Oracle wordbook in LibO
On Sat, Jan 08, 2011 at 12:43:43AM +0100, Andrea Pescetti wrote: Petr Mladek wrote: Andrea Pescetti píše v Pá 07. 01. 2011 v 02:29 +0100: - It removes all the application names: Writer, Calc, Impress... Hmm, I am not sure if these are language independent names. Sophie, what do you think? As far as I know, the application names are typically untranslated and I don't know of any localization using translated names. I can say for sure that they were never translated in the Italian version, in 1.x, 2.x or 3.x. But it's good to check with Sophie, French tend to translate much more technical terms than Italian do! For language not written in Latin script they are likely to get transliterated, we certainly do that in Arabic. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Horizontal glyph adjustments are ignored with ICU layout
batch should do that (plus some clean up over the previous
one).
It should be tested with some CTL scripts including reordering and
lots of diacritics to check the edge cases are covered. The width
will also affect font fallback (calls from MultiSalLayout), so that
needs to be tested as well.
I've tested with fonts that make extensive use of combining marks and no
major problems so far, however width of fallback glyphs seems to be
miscalculated when followed by kerned glyphs but I'm yet to understand
what is going on with fallback. Testing with scripts that require glyph
reordering still needed, but I don't speak any.
Regards,
Khaled
--
Khaled Hosny
Arabic localiser and member of Arabeyes.org team
Free font developer
diff --git a/vcl/source/glyphs/gcach_layout.cxx b/vcl/source/glyphs/gcach_layout.cxx
index cda8749..cb0d342 100644
--- a/vcl/source/glyphs/gcach_layout.cxx
+++ b/vcl/source/glyphs/gcach_layout.cxx
@@ -534,12 +534,40 @@ bool IcuLayoutEngine::operator()( ServerFontLayout rLayout, ImplLayoutArgs rAr
aNewPos = Point( (int)(pPos-fX+0.5), (int)(pPos-fY+0.5) );
const GlyphMetric rGM = rFont.GetGlyphMetric( nGlyphIndex );
int nGlyphWidth = rGM.GetCharWidth();
+int nNewWidth = nGlyphWidth;
if( nGlyphWidth = 0 )
bDiacritic |= true;
// #i99367# force all diacritics to zero width
// TODO: we need mnOrigWidth/mnLogicWidth/mnNewWidth
else if( bDiacritic )
-nGlyphWidth = 0;
+nGlyphWidth = nNewWidth = 0;
+else
+{
+// Hack, find next +ve width glyph and calculate current
+// glyph width by substracting the two posituons
+const IcuPosition* pNextPos = pPos+1;
+for ( int j = i + 1; j = nRawRunGlyphCount; ++j, ++pNextPos )
+{
+if ( j == nRawRunGlyphCount )
+{
+nNewWidth = pNextPos-fX - pPos-fX;
+break;
+}
+
+LEGlyphID nNextGlyphIndex = pIcuGlyphs[j];
+if( (nNextGlyphIndex == ICU_MARKED_GLYPH)
+|| (nNextGlyphIndex == ICU_DELETED_GLYPH) )
+continue;
+
+const GlyphMetric rNextGM = rFont.GetGlyphMetric( nNextGlyphIndex );
+int nNextGlyphWidth = rNextGM.GetCharWidth();
+if ( nNextGlyphWidth 0 )
+{
+nNewWidth = pNextPos-fX - pPos-fX;
+break;
+}
+}
+}
// heuristic to detect glyph clusters
bool bInCluster = true;
@@ -593,7 +621,8 @@ bool IcuLayoutEngine::operator()( ServerFontLayout rLayout, ImplLayoutArgs rAr
nGlyphFlags |= GlyphItem::IS_DIACRITIC;
// add resulting glyph item to layout
-const GlyphItem aGI( nCharPos, nGlyphIndex, aNewPos, nGlyphFlags, nGlyphWidth );
+GlyphItem aGI( nCharPos, nGlyphIndex, aNewPos, nGlyphFlags, nGlyphWidth );
+aGI.mnNewWidth = nNewWidth;
rLayout.AppendGlyph( aGI );
++nFilteredRunGlyphCount;
nLastCharPos = nCharPos;
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [FIXED] Re: debug build fails because graphite ./configure not up to date
On Sat, Jan 15, 2011 at 08:16:55PM +, Caolán McNamara wrote: On Sat, 2011-01-15 at 00:43 +0100, Lionel Elie Mamane wrote: Hi, A build with --enable-debug (or is it --enable-dbgutil?) fails in graphite... for a problem already corrected in graphite's configure.ac, but its configure is outdated and thus the problem still surfaces. Ah, I see. So I've now added a patch into that graphite module to sync the configure.ac logic into configure. Before I got to the point of trying to disable -Werror (and understanding why it was enabled in the first place), I fixed one of the warnings. Patch attached, still does not hurt to apply janitorialy :) Well, we do occasionally patch those external modules, but try to avoid it. The ideal place to send patches to graphite would be to the upstream graphite project and poke them to release a new update at some stage and then just upgrade to the latest graphite. BTW, Graphite engine is being re-written into a more stable engine (the current engine is crashy, or so I read), so it might be a good time to consider switching over to the new engine. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-users] Re: Which Unicode Standard LibreOffice uses...?
On Tue, Jan 25, 2011 at 09:07:56PM +0100, Cor Nouws wrote: Hi amine, amine amine wrote (24-01-11 21:24) LibO renders well the characters of the Arabic_Presentation_Forms-Bhttp://en.wiktionary.org/wiki/Appendix:Unicode/Arabic_Presentation_Forms-B . The problem is when reopening an exported PDF with LibO-Draw+PDFImport-extension and this Unicode Block has just been added recetly to the Unicode standard, that's why i'm asking. Ah, understand this now. Most likely is that LibO provides what OOo has in this area. Therefore I cc the dev-list. If necessary, a request at d...@openoffice.org (cc e...@openoffice.org, Eike Rathke), will help. Sorry, but I don't see what the issue being discussed here? And Arabic Presentation Forms have been in Unicode since version 2 or something. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Re: Horizontal glyph adjustments are ignored with ICU layout
On Fri, Jan 28, 2011 at 02:17:44PM +, Caolán McNamara wrote: Can we take it that your submission is under our recommended LGPLv3+/MPL licence ? Sure, this and any future submissions are LGPLv3+/MPL licensed. -- Khaled Hosny Egyptian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Re: Horizontal glyph adjustments are ignored with ICU layout
On Fri, Jan 28, 2011 at 02:17:44PM +, Caolán McNamara wrote: On Wed, 2011-01-26 at 17:03 +, Caolán McNamara wrote: On Wed, 2011-01-26 at 11:22 +0100, Jan Holesovsky wrote: Anybody here with ideas what we can do so that the patch helps Khaled, and is as safe as possible? - so that we can commit it, and fix the consequences later if anything happens? Where things are most likely to go wrong are with e.g. Indic text. What's ideally needed is some before and after tests with e.g. Hindi, Tamil, text that needs (the infamous) reordering processing. Ok, so I pulled down our RedHat Indic test cases and they appear to be the same before and after for this, so it doesn't obviously break anything. It seems more of a band-aid than a full fix to me, but it does improve the attached to fdo#31016 test case. Indeed. A real long term fix is to drop ICU layout engine altogether and switch to HarfBuzz, however HarfBuzz lacks Indic shaper right now (promised to be there by March), once it have one we should consider doing so (I'd try to give a hand). So I've pushed this now and added a little one-liner define around the relevant bit to make it easy to disable if any problems do arise. So thanks for this, CTL rendering is rather tricky, and while there's been a fair amount of work on Indic languages, Arabic is probably the one in worst shape. Next on the list is the horribly broken Kashida justification and make it optional. Regards, Khaled -- Khaled Hosny Egyptian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Re: Horizontal glyph adjustments are ignored with ICU layout
On Fri, Feb 04, 2011 at 11:00:34AM +, Michael Meeks wrote: On Thu, 2011-02-03 at 23:27 +0200, Khaled Hosny wrote: Indeed. A real long term fix is to drop ICU layout engine altogether and switch to HarfBuzz, however HarfBuzz lacks Indic shaper right now (promised to be there by March), once it have one we should consider doing so (I'd try to give a hand). Oooh ! :-) that would be brilliant :-) if we can get that great big (13 +Mb) blob of ICU out of the codebase, and substitute harfbuzz I'd be thrilled :-) HarfBuzz can do the layout part, but we still need a Unicode library though it need not to be the monstrous ICU. Regards, Khaled -- Khaled Hosny Egyptian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] No full justification in master?
In locally built libreoffice master I can't get full justification; text is kept left aligned. I tested with the distro packaged 3.3.1 and justification is fine. Can anyone confirm this, or it is just me? Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] No full justification in master?
On Tue, Mar 01, 2011 at 05:19:36PM +0100, Thomas Arnhold wrote: Hi Khaled, On 03/01/2011 05:10 PM, Khaled Hosny wrote: In locally built libreoffice master I can't get full justification; text is kept left aligned. I tested with the distro packaged 3.3.1 and justification is fine. Can anyone confirm this, or it is just me? Yes, I can confirm this! I've tested the 3.3.1 Gentoo version - works fine. But for git master it won't do anything. Reported on bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34920 -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] fixing kashida insertion
On Tue, Mar 15, 2011 at 10:32:59PM +0700, Martin Hosken wrote: Dear Arabic experts, The current kashida insertion implementation in libo is, to put it mildly, a disaster. Indeed! As I see it there are a few options open to us: 1. Get it right. This is really hard and beyond my capabilities in the time I have available for this. But if someone wants to work out the preferred location for each word and then insert there, then go for it. 2. Implement dumb kashida placement that says: you can insert a kashida at any joining of two characters. This should be doable (famous last words) based on Unicode properties. There is a bit less dump algorithm used by IE and also implemented in Qt: http://www.microsoft.com/middleeast/msdn/JustifyingText-CSS.aspx It shouldn't be hard to implement (though I don't completely agree with priority 5 in the table; a Baa followed by Yaa should never ever get a Kashida in a Naskh or Nastaliq font). 3. Don't do kashida insertion at all. This is probably better than the bad insertion we currently have. In either case this should be an option, there are many high quality fonts that any non highly sophosticated Kashida algorithm will fail for them (any good Nastaliq font for example). I'm willing to have a go at 2 or 3. An alternative would be to add a switch in say Options/Language Settings/Writing Aids/Options or Options/Language Settings/Complex Text Layout to enable/disable kashida insertion. Such UI stuff is beyond me at the moment. I'd suggest having a more accessible option (MS Office 2007 combines the three full justification settings in the same full justification button in the toolbar which makes it very accessible IMO), but it is up to who will actually right the code. This is one of the most broken aspects of OOo/LO for Arabic users, I was planing to play with it but unfortunately I'll not be able to put much effort into this. Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features, hacky patch
On Fri, Mar 30, 2012 at 03:27:39PM +0100, Caolán McNamara wrote: On Fri, 2012-03-30 at 16:13 +0200, Khaled Hosny wrote: If there is interest in this, I can try implementing optional HarfBuzz support next to ICU so we can experiment more with this (though I'm not the best person to do this, but I can try). Can't hurt to give it a go anyway. Even epic failure can point the next person in the right way to go. Yeah lacking Indic shaping would be a problem for right now. Indic scripts are supported now (git master, not released yet), and given HarfBuzz track record, it should even be better than ICU layout engine which is essentially put on ventilator (pun intended), so now is a good time to experiment, but I didn't manage to try doing it yet. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features, hacky patch
On Sat, Jul 21, 2012 at 03:08:20AM +0200, Khaled Hosny wrote:
On Fri, Mar 30, 2012 at 03:27:39PM +0100, Caolán McNamara wrote:
On Fri, 2012-03-30 at 16:13 +0200, Khaled Hosny wrote:
If there is interest in this, I can try implementing optional HarfBuzz
support next to ICU so we can experiment more with this (though I'm not
the best person to do this, but I can try).
Can't hurt to give it a go anyway. Even epic failure can point the next
person in the right way to go. Yeah lacking Indic shaping would be a
problem for right now.
Indic scripts are supported now (git master, not released yet), and
given HarfBuzz track record, it should even be better than ICU layout
engine which is essentially put on ventilator (pun intended), so now is
a good time to experiment, but I didn't manage to try doing it yet.
Here is a very crude, WIP patch. It adds --enable-harfbuzz configure
option, plus some (very broken) harfbuzz layout code, but I can't get
the ENABLE_HARFBUZZ to propagate in and thus can't do any testing
because the code is never compiled. I appreciate any insights on how to
get this to work.
Regards,
Khaled
diff --git a/RepositoryExternal.mk b/RepositoryExternal.mk
index 26676a7..4e0fc20 100644
--- a/RepositoryExternal.mk
+++ b/RepositoryExternal.mk
@@ -1110,6 +1110,29 @@ endef
endif # ENABLE_TELEPATHY
+ifeq ($(ENABLE_HARFBUZZ),TRUE)
+
+define gb_LinkTarget__use_harfbuzz
+$(call gb_LinkTarget_set_include,$(1),\
+ $$(INCLUDE) \
+ $(HARFBUZZ_CFLAGS) \
+)
+
+$(call gb_LinkTarget_add_libs,$(1),\
+ $(HARFBUZZ_LIBS) \
+)
+
+endef
+
+else # !ENABLE_HARFBUZZ
+
+define gb_LinkTarget__use_harfbuzz
+
+endef
+
+endif # ENABLE_HARFBUZZ
+
+
ifeq ($(SYSTEM_DB),YES)
define gb_LinkTarget__use_berkeleydb
diff --git a/config_host.mk.in b/config_host.mk.in
index 5e24730..3f3bf1f 100644
--- a/config_host.mk.in
+++ b/config_host.mk.in
@@ -116,6 +116,7 @@ export ENABLE_GSTREAMER=@ENABLE_GSTREAMER@
export ENABLE_GTK3=@ENABLE_GTK3@
export ENABLE_GTK=@ENABLE_GTK@
export ENABLE_GTK_PRINT=@ENABLE_GTK_PRINT@
+export ENABLE_HARFBUZZ=@ENABLE_HARFBUZZ@
export ENABLE_HEADLESS=@ENABLE_HEADLESS@
export ENABLE_TDEAB=@ENABLE_TDEAB@
export ENABLE_TDE=@ENABLE_TDE@
@@ -199,6 +200,8 @@ export GUIBASE=@GUIBASE@
export GUIBASE_FOR_BUILD=@GUIBASE_FOR_BUILD@
export GUI_FOR_BUILD=@GUI_FOR_BUILD@
export GXX_INCLUDE_PATH=@GXX_INCLUDE_PATH@
+export HARFBUZZ_FLAGS=@HARFBUZZ_CFLAGS@
+export HARFBUZZ_LIBS=@HARFBUZZ_LIBS@
export HAVE_CXX0X=@HAVE_CXX0X@
export HAVE_GCC_AVX=@HAVE_GCC_AVX@
export HAVE_GCC_GGDB2=@HAVE_GCC_GGDB2@
diff --git a/configure.in b/configure.in
index 980a2fb..86334ce 100644
--- a/configure.in
+++ b/configure.in
@@ -796,6 +796,11 @@ AC_ARG_ENABLE(gio,
[Determines whether to use the GIO support.]),
,enable_gio=no)
+AC_ARG_ENABLE(harfbuzz,
+AS_HELP_STRING([--enable-harfbuzz],
+[Determines whether to use HarfBuzz text layout engine.]),
+,enable_harfbuzz=no)
+
AC_ARG_ENABLE(telepathy,
AS_HELP_STRING([--enable-telepathy],
[Determines whether to enable Telepathy for collaboration.]),
@@ -8969,6 +8974,28 @@ AC_SUBST([GTK_PRINT_LIBS])
dnl ===
+dnl Check whether the HarfBuzz libraries are available.
+dnl ===
+
+ENABLE_HARFBUZZ=
+HARFBUZZ_CFLAGS=
+HARFBUZZ_LIBS=
+
+AC_MSG_CHECKING([whether to enable HarfBuzz support])
+if test $_os != WINNT -a $_os != Darwin -a $enable_harfbuzz = yes; then
+ENABLE_HARFBUZZ=TRUE
+AC_MSG_RESULT([yes])
+PKG_CHECK_MODULES( HARFBUZZ, harfbuzz = 0.9.0 )
+else
+AC_MSG_RESULT([no])
+fi
+
+AC_SUBST(ENABLE_HARFBUZZ)
+AC_SUBST(HARFBUZZ_CFLAGS)
+AC_SUBST(HARFBUZZ_LIBS)
+
+
+dnl ===
dnl Check whether the Telepathy libraries are available.
dnl ===
diff --git a/vcl/generic/glyphs/gcach_layout.cxx b/vcl/generic/glyphs/gcach_layout.cxx
index cd6b96c..be327e2 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -35,9 +35,14 @@
#include sal/alloca.h
#include rtl/instance.hxx
+#ifdef ENABLE_HARFBUZZ
+#include hb-ft.h
+#include hb-icu.h
+#else
#include layout/LayoutEngine.h
#include layout/LEFontInstance.h
#include layout/LEScripts.h
+#endif // ENABLE_HARFBUZZ
#include unicode/uscript.h
#include unicode/ubidi.h
@@ -156,6 +161,99 @@ bool ServerFontLayoutEngine::operator()( ServerFontLayout rLayout, ImplLayoutAr
return true;
}
+#ifdef ENABLE_HARFBUZZ
+class HbLayoutEngine : public ServerFontLayoutEngine
+{
+private:
+
+public:
+HbLayoutEngine( ServerFont );
+virtual ~HbLayoutEngine();
+
+virtual booloperator()( ServerFontLayout, ImplLayoutArgs );
+};
+
+HbLayoutEngine::HbLayoutEngine( ServerFont rServerFont )
+: mrServerFont( rFont
Re: Modern font features, hacky patch
On Sat, Jul 21, 2012 at 09:51:09PM +0200, Matúš Kukan wrote: On 21 July 2012 18:20, Khaled Hosny khaledho...@eglug.org wrote: Here is a very crude, WIP patch. It adds --enable-harfbuzz configure option, plus some (very broken) harfbuzz layout code, but I can't get the ENABLE_HARFBUZZ to propagate in and thus can't do any testing because the code is never compiled. I appreciate any insights on how to get this to work. +export HARFBUZZ_FLAGS=@HARFBUZZ_CFLAGS@ should be +export HARFBUZZ_CFLAGS=@HARFBUZZ_CFLAGS@ You want to add: +$(call gb_LinkTarget_add_defs,$(1),\ +-DENABLE_HARFBUZZ \ +) into RepositoryExternal.mk and use it as +$(eval $(call gb_Library_use_externals,vcl,harfbuzz)) in vcl/Library_vcl.mk I tried this already but didn't work, now I why, thanks. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Enable CTL for Default?
On Tue, Jun 19, 2012 at 12:52:24PM -0500, Norbert Thiebaud wrote: On Tue, Jun 19, 2012 at 8:41 AM, Christian Lohmaier * not treating CTL/Asian scripts as second class (quotenot to mention that Asian is a so ignorant orientalistic term in this context/quote) http://dictionary.reverso.net/english-definition/Orientalistic I'm quite confused as to what was meant by this quote. The option named Asian is really about vertical text layout and other features of CJK writing systems. Asia is such a large piece of the land that virtually all writing systems in use today are used in large parts of it, which shows how ignorant an option name it is, treating Asians as some mysterious group of people doing exotic things AKA Orientalism (in the bad meaning of it). So if this option is to stay, it should be given a name that reflects what it actually does (and even if it goes, there are many instances of Asian in the UI that should be given sensible names). Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] Enable CTL for Default?
On Thu, Jun 28, 2012 at 10:21:57AM +0200, Stefan Knorr (Astron) wrote: * I am not sure about Cursor Movement, but I've tried the options and visual seems to behave rather buggy – if it weren't it would likely be the best option I always set it to visual, logical seems very unprediuctable to me (i.e. I can't usually tell if the right arrow will move the cursor left or right at ant given position). * the Digits option: it could find a new home in the Languages tab or it could be removed completely, with it being set to Context always This have to be kept, in Arabic countries to the west of Egypt the European (AKA Arabic) digits are always used. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: On SSL library support
On Fri, May 04, 2012 at 03:16:59PM +0200, Enrico Weigelt wrote: Otherwise it's practical use is limited to pure desktop-only environments. Of course, given that LibreOffice is not a desktop application, oh wait... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: On SSL library support
On Fri, May 04, 2012 at 03:57:49PM +0200, Enrico Weigelt wrote: On Fri, May 04, 2012 at 03:16:59PM +0200, Enrico Weigelt wrote: Otherwise it's practical use is limited to pure desktop-only environments. Of course, given that LibreOffice is not a desktop application, oh wait... This statement was on Fedora's global consolidation project. Please always keep the context. And why this is being discussed here in *LibreOffice* mailing list? :) Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features, hacky patch
On Fri, Sep 07, 2012 at 05:18:46PM +0100, Caolán McNamara wrote: On Sat, 2012-07-21 at 18:20 +0200, Khaled Hosny wrote: Here is a very crude, WIP patch. It adds --enable-harfbuzz configure option, plus some (very broken) harfbuzz layout code, but I can't get the ENABLE_HARFBUZZ to propagate in and thus can't do any testing because the code is never compiled. I appreciate any insights on how to get this to work. You need to put harfbuzz in the gb_Library_use_externals section of Library_vcl.mk (or whichever is the right .mk file in vcl) It would be nice to get this feature in as a compile time option for experimenting with. I’ve some code that more or less works (as in displaying some text), but it crashes like hell, I'm yet to figure out what is going on (I think I've to override more members of ServerFontLayout to make things saner). Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need help to generate patch with git
On Tue, Aug 30, 2011 at 11:29:09PM +0200, Regina Henschel wrote: Hi all, I'm still learning to use git and need some help. I have made a patch for issue 34431. But after I used the 'commit' command I noticed, that I had to change a file, which needs another 'commit'. Now the command 'format-patch' has produced two files, one for each commit. Is there a way, to get _one_ patch file? For the second commit use `git commit --ammend`. Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need help to generate patch with git
On Wed, Aug 31, 2011 at 03:11:58AM +0200, Eike Rathke wrote: Hi Khaled, On Wednesday, 2011-08-31 02:05:10 +0200, Khaled Hosny wrote: Now the command 'format-patch' has produced two files, one for each commit. Is there a way, to get _one_ patch file? For the second commit use `git commit --ammend`. That works only on tip though to replace the current top commit. Or did I miss something? `git rebase` is your friend: http://help.github.com/rebase/ Regards, Khaled -- Khaled Hosny Egyptian Arab signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Bringing some sanity to interline spacing
On Thu, Sep 01, 2011 at 02:13:34AM +0200, Eike Rathke wrote: Hi Khaled, On Monday, 2011-08-29 20:21:47 +0200, Khaled Hosny wrote: Wow, way cool stuff! :-) :) #38683[5] is another example of problems caused by this. I'll set that bug to fixed with a remark to verify as I don't have a usable font for this. This only done for 'unx' similar work is needed for 'win' and 'aqua', but I'm not familiar with these platforms and can't test on it. Is handling on those platforms similar broken? I did no testing, and I'm not familiar with other platforms APIs, but there seem to be a nCJKExtLeading hack in vcl/win/source/gdi/salgdi3.cxx and a comment above it suggests that typo metrics are not currently used. Btw, please tag mails with attached patches with [PATCH] in the subject. Sorry, missed that. Regards, Khaled -- Khaled Hosny Egyptian Arab signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] some cleanup of Kashida justification code
On Thu, Sep 01, 2011 at 03:07:36AM +0200, Eike Rathke wrote: Hi Khaled, On Thursday, 2011-09-01 02:54:36 +0200, Eike Rathke wrote: Nice clean-up, pushed to master http://cgit.freedesktop.org/libreoffice/core/commit/?id=6825533b8d93f92a66558a9b6295003ceba52917 Forgot to mention [PUSHED] in the subject and that I changed all +#define isAinChar(c)IS_JOINING_GROUP(c, AIN) to have parentheses around the macro parameter's use +#define isAinChar(c)IS_JOINING_GROUP((c), AIN) Thanks [otherwise macros are evil anyway ;-] Indeed, but it looks better this way than having a dozen and half of one line functions each is called at most once. BTW, I see you merged the three patches in one commit, though I thought splitting them into more confined changes would be preferred. Is there any general policy for this that I can follow in future patches? Regards, Khaled -- Khaled Hosny Egyptian Arab signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] some cleanup of Kashida justification code
On Wed, Aug 31, 2011 at 10:32:35PM -0400, Kohei Yoshida wrote: On Thu, 2011-09-01 at 03:15 +0200, Khaled Hosny wrote: BTW, I see you merged the three patches in one commit, though I thought splitting them into more confined changes would be preferred. Is there any general policy for this that I can follow in future patches? Well, I started this page http://wiki.documentfoundation.org/Development/Patch_Handling_Guideline hoping to have it as a central place to gather recommended practices for submitting and integrating patches. So, this is probably the closest to what you are asking for. As for whether to combine commits or keep them separate, we generally try to have each commit a distinct purpose. But beyond that, it's really down to the discretion of the individual developers. If you are making complex changes, it's probably a good idea to make the changes separate, to make it easier for the reviewer to review. OTOH, if you are making small-ish and simpli-sh changes here and there for a single purpose, then it may be a good idea to combine them into a single commit. So, it depends on individual cases, I guess. Thanks for the reply and the wiki page, I think things are clear enough now. Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Thu, Sep 01, 2011 at 10:03:40AM +0100, Caolán McNamara wrote: On Wed, 2011-08-31 at 23:54 -0600, Tor Lillqvist wrote: The attached patch is an attempt to bring some sanity to the situation: It seems that you have investigate this quite deeply and I would love to commit and push your patch. However, I am a bit scared. Could somebody else who actually understands the issues involved have a look? I think we're all too chicken to man-up and look at this one :-) I guess the major fear isn't that your code is wrong, it's probably right, it's what stuff relying on the old way of doing things will change. I've been planning, but delayed on tracking down a mystery 2 point offset :-), to put together a did my layout change regression test which would have been perfect to test this. It is very likely to cause re-flowing (at least different line count per page) for many documents, but on the other hand the old behaviour was just wrong (and have been wrong for two decades now, since the introduction of TrueType). caolan-tor: I suggest bunging this in for now, but putting the old algorithm behind an getenv(SAL_OLD_METRICS) or something for easy side-by-side testing ? I'd be interested in knowing what effects the change has on typical fonts as opposed to the edge cases, i.e. does text rendered in Liberation Serif, Sans, Monotype stay basically the same. I just tested with a simple lorem ipsum document with Liberation Serif; page count went down from 24 to 22 after applying the patch, a quite a drastic change I think :( One the bright side, I'm no longer getting oversized buttons and combo boxes. Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Thu, Sep 01, 2011 at 02:43:53PM +0100, Caolán McNamara wrote: On Thu, 2011-09-01 at 11:47 +0200, Khaled Hosny wrote: I just tested with a simple lorem ipsum document with Liberation Serif; page count went down from 24 to 22 after applying the patch Comparison with MSWord will be good to do too, with/without the use extra leading compatibility option. MSWord is not known for its sane handling of font metrics, and I have been told recent (2007-) broke it even further. Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Thu, Sep 01, 2011 at 12:12:28PM +0200, Eike Rathke wrote: This only done for 'unx' similar work is needed for 'win' and 'aqua', but I'm not familiar with these platforms and can't test on it. I wonder if this patch will then introduce significant rendering differences between platforms? Or do we have such anyway already (even if the same fonts are present)? Even if it may currently render differently, I think using the correct font metrics on one system where people complained about it is a step into the right direction. We use different layout engines on unx,mac,win and hopefully each system positions glyphs as accurately as possible when given the right input. I had this idea in mind for a while: unifying the text layout code of all platforms, using HarfBuzz, Cairo, FreeType etc. This would give us more control over text layout (e.g. we can support user selectable OpenType features and more typographic niceties) as well as consistent text rendering on all platforms. The downside is that might give the user different experience between LibreOffice and applications using native APIs (though it can be a good thing sometimes, for example apple does not support Indic scripts in their OpenType implementation, while FOSS font stack does). It also means less code to maintain and debug. But I'm still far from understanding the current text layout code to seriously propose this. Mozilla is moving into this direction as well. Regards, Khaled -- Khaled Hosny Egyptian Arab signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Thu, Sep 01, 2011 at 10:31:14AM +0200, Khaled Hosny wrote:
It shouldn't be hard to adapt GetFontMetric implementation in
vcl/win/source/gdi/salgdi3.cxx to use the new function and have the same
logic as the unix code.
Here is a patch that, hopefully, does this, but I couldn't test it and
it might not even compile.
Regards,
Khaled
--
Khaled Hosny
Egyptian
Arab
From 0743024ea07abd98b19eaf1ffecd6bb111681c58 Mon Sep 17 00:00:00 2001
From: Khaled Hosny khaledho...@eglug.org
Date: Fri, 2 Sep 2011 10:24:16 +0200
Subject: [PATCH] Use GetOutlineTextMetrics instead of GetTextMetrics
Follow up of commit 3364fef
GetOutlineTextMetrics returns an OUTLINETEXTMETRIC struct containing
typographic ascent/descent among other font metrics.
The CKJ external leading hack have been removed as well.
---
vcl/win/source/gdi/salgdi3.cxx | 51 +++-
1 files changed, 14 insertions(+), 37 deletions(-)
diff --git a/vcl/win/source/gdi/salgdi3.cxx b/vcl/win/source/gdi/salgdi3.cxx
index fdb9296..ad8dbe0 100644
--- a/vcl/win/source/gdi/salgdi3.cxx
+++ b/vcl/win/source/gdi/salgdi3.cxx
@@ -1764,24 +1764,24 @@ void WinSalGraphics::GetFontMetric( ImplFontMetricData* pMetric, int nFallbackLe
pMetric-maName = reinterpret_castconst sal_Unicode*(aFaceName);
// get the font metric
-TEXTMETRICA aWinMetric;
-const bool bOK = GetTextMetricsA( mhDC, aWinMetric );
+OUTLINETEXTMETRICA aWinMetric;
+const bool bOK = GetOutlineTextMetricsA( mhDC, aWinMetric );
// restore the HDC to the font in the base level
SelectFont( mhDC, hOldFont );
if( !bOK )
return;
// device independent font attributes
-pMetric-meFamily = ImplFamilyToSal( aWinMetric.tmPitchAndFamily );;
-pMetric-mbSymbolFlag = (aWinMetric.tmCharSet == SYMBOL_CHARSET);
-pMetric-meWeight = ImplWeightToSal( aWinMetric.tmWeight );
-pMetric-mePitch= ImplMetricPitchToSal( aWinMetric.tmPitchAndFamily );
-pMetric-meItalic = aWinMetric.tmItalic ? ITALIC_NORMAL : ITALIC_NONE;
+pMetric-meFamily = ImplFamilyToSal( aWinMetric.otmTextMetrics.tmPitchAndFamily );;
+pMetric-mbSymbolFlag = (aWinMetric.otmTextMetrics.tmCharSet == SYMBOL_CHARSET);
+pMetric-meWeight = ImplWeightToSal( aWinMetric.otmTextMetrics.tmWeight );
+pMetric-mePitch= ImplMetricPitchToSal( aWinMetric.otmTextMetrics.tmPitchAndFamily );
+pMetric-meItalic = aWinMetric.otmTextMetrics.tmItalic ? ITALIC_NORMAL : ITALIC_NONE;
pMetric-mnSlant= 0;
// device dependend font attributes
-pMetric-mbDevice = (aWinMetric.tmPitchAndFamily TMPF_DEVICE) != 0;
-pMetric-mbScalableFont = (aWinMetric.tmPitchAndFamily (TMPF_VECTOR|TMPF_TRUETYPE)) != 0;
+pMetric-mbDevice = (aWinMetric.otmTextMetrics.tmPitchAndFamily TMPF_DEVICE) != 0;
+pMetric-mbScalableFont = (aWinMetric.otmTextMetrics.tmPitchAndFamily (TMPF_VECTOR|TMPF_TRUETYPE)) != 0;
if( pMetric-mbScalableFont )
{
// check if there are kern pairs
@@ -1798,34 +1798,11 @@ void WinSalGraphics::GetFontMetric( ImplFontMetricData* pMetric, int nFallbackLe
}
// transformation dependend font metrics
-pMetric-mnWidth= static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmAveCharWidth );
-pMetric-mnIntLeading = static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmInternalLeading );
-pMetric-mnExtLeading = static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmExternalLeading );
-pMetric-mnAscent = static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmAscent );
-pMetric-mnDescent = static_castint( mfFontScale[nFallbackLevel] * aWinMetric.tmDescent );
-
-// #107888# improved metric compatibility for Asian fonts...
-// TODO: assess workaround below for CWS = extleading
-// TODO: evaluate use of aWinMetric.sTypo* members for CJK
-if( mpWinFontData[nFallbackLevel] mpWinFontData[nFallbackLevel]-SupportsCJK() )
-{
-pMetric-mnIntLeading += pMetric-mnExtLeading;
-
-// #109280# The line height for Asian fonts is too small.
-// Therefore we add half of the external leading to the
-// ascent, the other half is added to the descent.
-const long nHalfTmpExtLeading = pMetric-mnExtLeading / 2;
-const long nOtherHalfTmpExtLeading = pMetric-mnExtLeading - nHalfTmpExtLeading;
-
-// #110641# external leading for Asian fonts.
-// The factor 0.3 has been confirmed with experiments.
-long nCJKExtLeading = static_castlong(0.30 * (pMetric-mnAscent + pMetric-mnDescent));
-nCJKExtLeading -= pMetric-mnExtLeading;
-pMetric-mnExtLeading = (nCJKExtLeading 0) ? nCJKExtLeading : 0;
-
-pMetric-mnAscent += nHalfTmpExtLeading;
-pMetric-mnDescent += nOtherHalfTmpExtLeading;
-}
+pMetric-mnWidth = static_castint( mfFontScale[nFallbackLevel
Re: [Libreoffice] Bringing some sanity to interline spacing
On Fri, Sep 02, 2011 at 11:23:14AM +0100, Caolán McNamara wrote: On Thu, 2011-09-01 at 23:31 +0200, Khaled Hosny wrote: On Thu, Sep 01, 2011 at 02:43:53PM +0100, Caolán McNamara wrote: On Thu, 2011-09-01 at 11:47 +0200, Khaled Hosny wrote: I just tested with a simple lorem ipsum document with Liberation Serif; page count went down from 24 to 22 after applying the patch Comparison with MSWord will be good to do too, with/without the use extra leading compatibility option. MSWord is not known for its sane handling of font metrics, and I have been told recent (2007-) broke it even further. Hum, ending up with .docs, .docxs, .rtfs that layout even further from their original how-they-layout-in-word, while pre-existing .odts and so forth also change layout sounds somewhat worrying :-). We may have to cook up a use-old-school-metrics compatibility flag or something like that along the lines of some similar flags we already have. I might try and play around the area. This would even be better. With my font developer hat on I'd prefer enforcing standard compliance (old behaviour is against OpenType recommendation), but as long as there is a way to get the correct behaviour I'm fine. Regards, Khaled (who is suffering right now from this very same issue with MS Word) -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Sun, Sep 04, 2011 at 02:39:37PM +0200, Eike Rathke wrote: But before going there, I just need to make sure that we are on the same page wrt keeping the new algorithm and moving on to fixing whatever needs fixing. I'm not sure we want to keep the new algorithm as default, given that there are probably many areas in several applications to be adapted to the new behavior. Maybe best we make that an option until necessary changes are done. Opinions? That fine with me, even having the new algorithm as an off by default option would be fine. Regards, Khaled -- Khaled Hosny Egyptian Arab signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bringing some sanity to interline spacing
On Fri, Sep 09, 2011 at 06:39:52PM +0200, Eike Rathke wrote: Hi Khaled, On Friday, 2011-09-02 18:21:50 +0200, Khaled Hosny wrote: MSWord is not known for its sane handling of font metrics, and I have been told recent (2007-) broke it even further. Hum, ending up with .docs, .docxs, .rtfs that layout even further from their original how-they-layout-in-word, while pre-existing .odts and so forth also change layout sounds somewhat worrying :-). We may have to cook up a use-old-school-metrics compatibility flag or something like that along the lines of some similar flags we already have. I might try and play around the area. This would even be better. With my font developer hat on I'd prefer enforcing standard compliance (old behaviour is against OpenType recommendation), but as long as there is a way to get the correct behaviour I'm fine. With http://cgit.freedesktop.org/libreoffice/core/commit/?id=052f181dad89ad34d90513bc9dcd3e3239727933 the new spacing is used only if SAL_USE_NEW_LINEHEIGHT=1 is set in the environment, else the old metrics are used. Thanks, though I was expecting a friendlier UI option, but I won't insist on that :) Khaled (who is suffering right now from this very same issue with MS Word) Which indicates even more that we can't switch just like that to the new metrics. There is a use typo metrics bit in OS/2 table that was introduced as a way for font developer to really opt for using typo metrics, I omitted checking for it for the sake of simplification. Now thinking more of it, I think we should check it and don't use the new method if it isn't set, however this does not really solve the combat ability issue since since many fonts already set it. Regards, Khaled -- Khaled Hosny Egyptian Arab signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need to add Arabic Math Symbols to LibreOffice Math
On Thu, Sep 15, 2011 at 11:53:22AM +0100, Caolán McNamara wrote: On Wed, 2011-09-14 at 03:37 +0200, Ibraheem Saed wrote: Hello everybody, LibreOffice Math doesn't support Arabic math symbols. I need to add the Arabic math symbols to LibreOffice Math Aligned from right to left. Arabic math symbols like are English math symbols; but writing is reversed (from right to left and symbols are opposite). Hmmm, Unicode technical report #25 seems to be the relevant documentation around this. http://www.unicode.org/Public/5.2.0/ucd/BidiMirroring.txt for the right to left forms which can be synthesized from existing unicode code points And the opentype rtlm table for including right to left forms in the font itself. It *looks* to me on a casual look through, that some support in our text rendering would be needed to take the text to be rendered, look up if the font has a rtlm mapping for the glyph, and if it doesn't then see if the font has a glyph for its BidiMirroring equivalent, and if not then try and just swap the glyph around ? We need more than mirroring bidi mirrored glyphs, we need also to be able to lay the whole formula from right to left (including things like sub and superscripts which ave to be on the left of base node) and apply bidi algorithm to individual tokens and not the whole formula. This W3 note gives an overview of laying out Arabic mathematical notation: http://www.w3.org/TR/arabic-math/ Also MathML3 now supports right to left math: http://www.w3.org/TR/MathML3/chapter3.html#presm.bidi On the other hand, LO's math rendering is quite boor compared to TeX, latest version of MS Word (which has a formula renderer based on TeX algorithms) or even Mozilla's. For their Office 2007, MS developed and new OpenType table, (MATH, implemented in their Cambria font) which can be seen as a modernisation of TeX concepts. There few free implementations of OpenType MATH and implementing it in LO would give it higher quality math layout and support for increasing number of OpenType math fonts. Regards, Khaled -- Khaled Hosny Egyptian Arab ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [ANNOUNCE] Changes to the build system: Env.Host.sh is dead so is the need to source the environment
On Sun, Feb 05, 2012 at 07:42:14PM -0600, Norbert Thiebaud wrote: HI all, I have pushed a series of commit that completely remove set_soenv.in and the creation of Env.Host.sh/Env.Build.sh Great! However, running git `grep set_soenv1`, shows many remnants of set_soenv.*, just in case someone knowledgeable about the build system wants to check them. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: OK to merge the fw? libraries in framework?
On Wed, Feb 08, 2012 at 06:39:05PM +0100, Michael Stahl wrote: On 08/02/12 18:10, Tor Lillqvist wrote: While trying to find easy ways to lower the number of (shared) libraries, which is more or less on the critical path for the Android work (the stupid run-time linker on Android has a low (from our perverse perspective) limit on the number of shared libraries that can be used at a time in a process), I started looking at the libraries built in the framework module (mnemonically and self-documentingly named fwe, fwi, fwk, fwl and fwm). well, yes, obviously the fwe stands for framework exports, fwi for framework imports, fwk for framework, fwl for framework library and fwm for framework module... no actually i just made that up ;) ROFL, you made my day :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Wrong screenshot in 3.5 features page
Not sure to which mailing list should I report this, so I'm sending to the one I'm subscribed to :) In http://www.libreoffice.org/download/3-5-new-features-and-fixes/, the screenshot under The Insert Movie and Sound dialog... actually is the one for Several GTK+ right-to-left interface glitches... few lines above. Regards Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Wrong screenshot in 3.5 features page
On Tue, Feb 14, 2012 at 02:37:32PM +0100, Andras Timar wrote: Hi Khaled, 2012/2/14 Khaled Hosny khaledho...@eglug.org: Not sure to which mailing list should I report this, so I'm sending to the one I'm subscribed to :) In http://www.libreoffice.org/download/3-5-new-features-and-fixes/, the screenshot under The Insert Movie and Sound dialog... actually is the one for Several GTK+ right-to-left interface glitches... few lines above. I'm sorry that we made a mistake with your feature. It is corrected now. Thanks :) Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Ligatures in arabic fonts
On Mon, Feb 27, 2012 at 01:11:03PM +0100, Tomáš Chvátal wrote: Hello guys, I have bug reported at gentoo [1] which I am not entirely sure how to sort out. I suspected graphite2 to be the culprit but it is indeed broken with both system and internal one. Also if I build the libreoffice on the same machine with generic ./autogen.sh build which pulls most of the packages as internal the feature works as desired. So my question is, do you know what area of LO is responsible for this ligatures and any suggestions how to debug this? This is likely to be an ICU issue, may be it is this issue: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=39955 and ICU bug ticket: http://bugs.icu-project.org/trac/ticket/8764 There is testcase attached to the bug which I can reproduce so anyone who can do so on different distro that built with system libs (debian) and confirm they have the issue or tell me that the issue is not present there would be helpful. No problem here with official 3.5 build as will as git master. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: A Desugn Suggestion
On Thu, Mar 01, 2012 at 11:06:41AM +, Arnold Bailson wrote: I realize that this may not be the right place for this suggestion. If that is so, my apologies: please pass it on to the correct place. I now have macular degeneration in my second eye. I find it convenient when reading to use a hand-held lighted magnifier and this has brought very clearly to my attention the business of moving attention across the page and then backtracking to the beginning of the next line. . I imagine it would not be insurmountably difficult to lay out alternate lines im opposite directions and this would remove the problem of wobbling onto the wrong line on the way back. If we could re-train are hence so as to read in alternating directions this might greatly improve the speed and comfort of reading for everyone. http://en.wikipedia.org/wiki/Boustrophedon “The old fellows stole all our best ideas!” — Frederic Goudy Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Question about less-than and greater-than in Arabic
Hi Kendy,
On Mon, Mar 19, 2012 at 09:51:24AM +0100, Jan Holesovsky wrote:
Hi Khaled,
I've got the following report:
- 8 -
The Arabic keyboard layout in X11 has the less-than sign () on the same
position as the left curly bracket ({) in the English keyboard layout.
Same for and }. If I type in the terminal, these two display as
printed on the Arabic keyboard. However, in both LibreOffice and gedit,
which support RTL, the and signs are swapped. So when I type 12, it
displays 21 aligned to right. I guess that someone has made the effort
to swap the symbols and this is the intended behaviour and that users
expect this. But I would be very grateful if some native speaker could
confirm this.
Please see the attached screenshot, showing the string 12 entered
into the gnome-terminal, gedit and LibreOffice.
- 8
Can you please help me to understand what is the correct, expected
behavior? :-)
Less than and greater than have the Unicode Bidi_Mirrored property which
means that a Unicode complaint application should mirror them if the
direction of text run is right to left (which is the right thing to do
since the base of greater than faces the first value, which is the right
one in case of Arabic, and vice versa), so LibreOffice and Gedit are
doing the right thing here, but the terminal does not seem to support
right to left and does no mirroring.
BTW, just 12 are not enough to determine the directionality since all
the three characters have weak direction property, so some application
will guess the direction from the language of the keyborad layout
currently active (very visible in Gedit, type 12 with Arabic and
English layouts and watch the difference though they are exactly the
same 3 characters).
On my Arabic keyboard, the printed less than and greater than symbols
match the mirrored form, and all the keyboards I've seen do the same,
and it matches MS's Arabic layout (I know because I submitted a patch
long ago to XkeyboardConfig that swaps the positron of all mirrored
characters in the Arabic layout so it matches user expectations).
Regards,
Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features, hacky patch
On Fri, Mar 30, 2012 at 01:11:59PM +0100, Caolán McNamara wrote: On Fri, 2012-03-30 at 11:39 +0200, Steve White wrote: Basic features == (Background reading: search for typographic features, font feature registry, layout tag registry.) Some features that really ought to be activated most of the time, in most scripts * ligatures for Latin and most alphabetic scripts * localized replacement (based on text language, region) * pair kerning * mark positioning So, I asked Steve to post to the list, so I could dump some experimental code to a wider audience with its context Lets put graphite aside for a moment, its something of a red herring really for a lot of these things. If we look at https://bugs.freedesktop.org/show_bug.cgi?id=31821 I've a patch there that shows that a lot of our woes with otf fonts is probably a simple bug/lack of implementation in out ServerFont::GetTable that it doesn't handle OpenType. freetype does it fine, but we're not using freetype to get the tables, but parsing them outselves. Patch at fdo#31821 a) hacks in using freetype to get the tables (does anyone know if there a freetype api to just get the offset of a table and not a full copy of it ?, we've already mmapped the file so we don't need to copy them) b) hacks in using the icu layout engine for all text, and not just for CTL text. I wonder if its just a performance reason that we have out own simple font engine for the non-CTL case ? c) overrides IcuFontFromServerFont::mapCharToGlyph to not filter out the zero width joiner glyphs before applying the gsub table. The icu Indic layout engine doesn't filter it, not sure why the non-Indic ones *do* filter it. So, I reckon we should continue to refactor out font handling code to remove various custom ttf/otf parsing and try and use more of the freetype apis so that LibreOffice gets to know about GSUB etc tables in opentype fonts, and maybe look into removing the simple font layout engine and just use the icu one for all fonts. For a while now I had the idea that we should move away from ICU layout engine (which is pretty dead and serious bugs aren't fixed anymore), and replace it with HarfBuzz, but HarfBuzz's Indic support is not finished (Arabic and simple scripts are fine) and I'm waiting for its next release for that. HarfBuzz is more active, more developer friendly (though under documented at the moment) and its code base have been widely used in free software applications (more tested) and is the most feature rich free OpenType implementation. HarfBuzz would make it much simpler to implement many of the points raised above, which would be near impossible with ICU layout engine. But regardless of the layout engine we use, this only affects non-Windows non-Mac platforms, while on Windows we use Uniscribe and on Mac we use, the now deprecated, ATSUI, which is IMHO another limitation that we should get rid of and move to a unified text layout engine in all platforms (which would solve lack of OpenType support on Mac). Firefox have been doing that lately, and IMO it has the best typographic support of all browsers. If there is interest in this, I can try implementing optional HarfBuzz support next to ICU so we can experiment more with this (though I'm not the best person to do this, but I can try). Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Mirroring gtk buttons
On Wed, Mar 06, 2013 at 05:45:57AM +, Issa Alkurtass wrote: Hello world, Any idea how to mirror gtk buttons in vcl? I need to mirror the combo box buttons in vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx for the RTL interface. (screenshot: http://i.imgur.com/XAnvum8.png) I thought this issue has been already fixed in 3.5, commit 0608cb3. You probably have LibreOffice and GTK using two different locales (e.g. LibreOffice is set to a right-to-left while the system locale is set to a left-to-right language). Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Mirroring gtk buttons
On Wed, Mar 06, 2013 at 11:38:14AM +, Issa Alkurtass wrote: Michael Meeks wrote on March 06, 2013 2:13 PM: Urk - so - then I guess it is a matter of persuading each of our captive gtk2 widgets to have the right RTL setting via: void gtk_widget_set_direction (GtkWidget*widget, GtkTextDirection dir); or perhaps I'm missing something ? Something like that yes, but this function is only concerned with text direction and ordering of items, not graphical orientation. We need something that flips or mirrors the widgets. AFAIK, gtk_widget_set_direction () controls the layout of UI elements as well. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Mirroring gtk buttons
On Wed, Mar 06, 2013 at 12:05:23PM +, Michael Meeks wrote: On Wed, 2013-03-06 at 11:38 +, Issa Alkurtass wrote: Something like that yes, but this function is only concerned with text direction and ordering of items, not graphical orientation. We need something that flips or mirrors the widgets. Well - I'd have a read around inside the gtk+ widget implementations themselves to see what they are using themselves to orient themselves :-) then we'll need to clobber that. widget_direction as you point out only sounds plausible ;-) The default direction of GTK widgets is locale dependant; it is set by a string in GTK's gettext catalogue, so if we can somehow trick GTK to use the same locale as LibreOffice UI, that would be a solution. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: A little info about ligatures and e.g. Calibri
On Sun, Feb 03, 2013 at 03:39:36PM +, Caolán McNamara wrote: FWIW, as it came up as a question in the main track FOSDEM LibreOffice talk, in vcl/generic/glyphs/gcach_layout.cxx see IcuLayoutEngine::layout and... if (rArgs.mnFlags SAL_LAYOUT_ENABLE_LIGATURES) nLayoutFlags |= LayoutEngine::kTypoFlagLiga; so ligatures are disabled by default unless SAL_LAYOUT_ENABLE_LIGATURES is enabled, and SAL_LAYOUT_ENABLE_LIGATURES is only set if TEXT_LAYOUT_ENABLE_LIGATURES is set on the outputdevice, and that doesn't happen anywhere as of yet :-( I was wondering about this a while ago, but thought it was just me not finding where the magic is. It would be no major problem to e.g. bubble up allowing those ligatures to be set explicitly via the UI, or e.g. defaulted on via a new compatibility flag for new docs, but the last time I played around with it I ran into the snag that with our current Linux rendering stack via cairo we get the unfortunate visual effect that ligatures appear bold in Calibri, etc. I see Calibri only, no etc's :), so blocking ligature support (which is so 80s, even MS Office now supports OpenType features for Latin) because is of a bug in a single font in certain configurations is overreacting IMHO. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: A little info about ligatures and e.g. Calibri
On Sun, Feb 03, 2013 at 04:15:00PM +, Caolán McNamara wrote: On Sun, 2013-02-03 at 17:58 +0200, Khaled Hosny wrote: I see Calibri only, no etc's :), so blocking ligature support (which is so 80s, even MS Office now supports OpenType features for Latin) because is of a bug in a single font in certain configurations is overreacting IMHO. *shrug*, its why I wasn't motivated to go and figure out a UI to enable/disable ligatures or see if a compatibility option was a better idea etc because I'd just get a slew of bugs that my text is bold. GTK have been enabling ligatures and other default OpenType features since ages (since before I started using computers :p), so probably the situation is not that bad. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] Add HarfBuzz support to the build system
Hi, I didn't know that it will submit each commit separately (git review), should I abandon this and the next commits and squash them into one? Also, there are some unresolved issues that I can't handle, may be submitting to gerrit wasn't the best idea after all. Regards, Khaled On Sun, Apr 21, 2013 at 08:19:15AM +, Khaled Hosny (via Code Review) wrote: Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/3517 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/17/3517/1 Add HarfBuzz support to the build system To be used in the next commit. No support for non-system build, yet. Change-Id: I6ee286d0c050a5ca650e7fb3692b0facccb5f0c0 --- M RepositoryExternal.mk M config_host.mk.in A config_host/config_harfbuzz.h.in M configure.ac M vcl/Library_vcl.mk 5 files changed, 64 insertions(+), 0 deletions(-) diff --git a/RepositoryExternal.mk b/RepositoryExternal.mk index df44d2d..2707a23 100644 --- a/RepositoryExternal.mk +++ b/RepositoryExternal.mk @@ -1186,6 +1186,39 @@ endif # SYSTEM_ICU +ifeq ($(SYSTEM_HARFBUZZ),YES) + +define gb_LinkTarget__use_harfbuzz +$(call gb_LinkTarget_set_include,$(1),\ + $$(INCLUDE) \ + $(HARFBUZZ_CFLAGS) \ +) +$(call gb_LinkTarget_add_libs,$(1),$(HARFBUZZ_LIBS)) + +endef + +else ifeq ($(SYSTEM_HARFBUZZ),NO) + +$(eval $(call gb_Helper_register_static_libraries,PLAINLIBS, \ + harfbuzz \ +)) +define gb_LinkTarget__use_harfbuzz +$(call gb_LinkTarget_use_unpacked,$(1),harfbuzz) +$(call gb_LinkTarget_set_include,$(1),\ + -I$(call gb_UnpackedTarball_get_dir,harfbuzz/include) \ + $$(INCLUDE) \ +) +$(call gb_LinkTarget_use_static_libraries,$(1),\ +harfbuzz \ +) + +endef + +else # DISABLED HARFBUZZ + +gb_LinkTarget__use_harfbuzz := + +endif # SYSTEM_HARFBUZZ ifeq ($(DISABLE_OPENSSL),YES) diff --git a/config_host.mk.in b/config_host.mk.in index 4256fa7..ad33e7d 100644 --- a/config_host.mk.in +++ b/config_host.mk.in @@ -122,6 +122,7 @@ export ENABLE_GIO=@ENABLE_GIO@ export ENABLE_GNOMEVFS=@ENABLE_GNOMEVFS@ export ENABLE_GRAPHITE=@ENABLE_GRAPHITE@ +export ENABLE_HARFBUZZ=@ENABLE_HARFBUZZ@ export ENABLE_GSTREAMER=@ENABLE_GSTREAMER@ export ENABLE_GSTREAMER_0_10=@ENABLE_GSTREAMER_0_10@ export ENABLE_GTK3=@ENABLE_GTK3@ @@ -196,6 +197,8 @@ export GPERF=@GPERF@ export GRAPHITE_CFLAGS=$(gb_SPACE)@GRAPHITE_CFLAGS@ export GRAPHITE_LIBS=$(gb_SPACE)@GRAPHITE_LIBS@ +export HARFBUZZ_CFLAGS=$(gb_SPACE)@HARFBUZZ_CFLAGS@ +export HARFBUZZ_LIBS=$(gb_SPACE)@HARFBUZZ_LIBS@ @x_Cygwin@ export GREP=@WIN_GREP@ export GSSAPI_LIBS=@GSSAPI_LIBS@ export GSTREAMER_0_10_CFLAGS=$(gb_SPACE)@GSTREAMER_0_10_CFLAGS@ @@ -478,6 +481,7 @@ export SYSTEM_GENCCODE=@SYSTEM_GENCCODE@ export SYSTEM_GENCMN=@SYSTEM_GENCMN@ export SYSTEM_GRAPHITE=@SYSTEM_GRAPHITE@ +export SYSTEM_HARFBUZZ=@SYSTEM_HARFBUZZ@ export SYSTEM_HSQLDB=@SYSTEM_HSQLDB@ export SYSTEM_HUNSPELL=@SYSTEM_HUNSPELL@ export SYSTEM_HYPH=@SYSTEM_HYPH@ diff --git a/config_host/config_harfbuzz.h.in b/config_host/config_harfbuzz.h.in new file mode 100644 index 000..b408f52 --- /dev/null +++ b/config_host/config_harfbuzz.h.in @@ -0,0 +1,6 @@ +#ifndef CONFIG_HARFBUZZ_H +#define CONFIG_HARFBUZZ_H + +#define ENABLE_HARFBUZZ 0 + +#endif diff --git a/configure.ac b/configure.ac index 2152487..6b844d6 100644 --- a/configure.ac +++ b/configure.ac @@ -720,6 +720,11 @@ [Enables the compilation of Graphite smart font rendering.]) ) +AC_ARG_ENABLE(harfbuzz, +AS_HELP_STRING([--enable-harfbuzz], +[Determines whether to use HarfBuzz text layout engine.]) +) + AC_ARG_ENABLE(fetch-external, AS_HELP_STRING([--disable-fetch-external], [Disables fetching external tarballs from web sources.]) @@ -8378,6 +8383,20 @@ AC_SUBST(ENABLE_GRAPHITE) dnl === +dnl HarfBuzz +dnl === +AC_MSG_CHECKING([whether to enable HarfBuzz support]) +if test $_os != WINNT -a $_os != Darwin test $enable_harfbuzz = -o $enable_harfbuzz != no; then +AC_MSG_RESULT([yes]) +ENABLE_HARFBUZZ=TRUE +AC_DEFINE(ENABLE_HARFBUZZ) +libo_CHECK_SYSTEM_MODULE([harfbuzz],[HARFBUZZ],[harfbuzz = 0.9.10]) +else +AC_MSG_RESULT([no]) +fi +AC_SUBST(ENABLE_HARFBUZZ) + +dnl === dnl Check for NPAPI interface to plug browser plugins into LibreOffice documents dnl === AC_MSG_CHECKING([whether to plug browser plugins into LibreOffice documents]) @@ -11880,6 +11899,7 @@ AC_CONFIG_HEADERS([config_host/config_features.h]) AC_CONFIG_HEADERS([config_host/config_global.h]) AC_CONFIG_HEADERS([config_host/config_graphite.h]) +AC_CONFIG_HEADERS([config_host
[Libreoffice-commits] core.git: config_host/config_harfbuzz.h.in config_host.mk.in configure.ac download.lst harfbuzz/ExternalPackage_harfbuzz.mk harfbuzz/ExternalProject_harfbuzz.mk harfbuzz/harfbuzz
Makefile.fetch |1 RepositoryExternal.mk| 33 RepositoryModule_host.mk |1 config_host.mk.in|4 + config_host/config_harfbuzz.h.in |6 ++ configure.ac | 20 +++ download.lst |1 harfbuzz/ExternalPackage_harfbuzz.mk | 34 harfbuzz/ExternalProject_harfbuzz.mk | 37 + harfbuzz/Makefile|7 ++ harfbuzz/Module_harfbuzz.mk | 22 harfbuzz/README |1 harfbuzz/UnpackedTarball_harfbuzz.mk | 18 ++ harfbuzz/harfbuzz.configure.patch.1 | 93 +++ vcl/Library_vcl.mk |1 vcl/Library_vclplug_gen.mk |1 16 files changed, 280 insertions(+) New commits: commit 7e389f4def1964ee38bb93b575926a089e84bae6 Author: Khaled Hosny khaledho...@eglug.org Date: Sat Apr 20 13:00:56 2013 +0200 Add HarfBuzz support to the build system To be used in the next commit. Change-Id: I6ee286d0c050a5ca650e7fb3692b0facccb5f0c0 Reviewed-on: https://gerrit.libreoffice.org/3517 Reviewed-by: Fridrich Strba fridr...@documentfoundation.org Tested-by: Fridrich Strba fridr...@documentfoundation.org diff --git a/Makefile.fetch b/Makefile.fetch index bfc882d..e683f28 100644 --- a/Makefile.fetch +++ b/Makefile.fetch @@ -112,6 +112,7 @@ $(WORKDIR)/download: $(BUILDDIR)/config_host.mk $(SRCDIR)/download.lst $(SRCDIR) $(call fetch_Optional,GLIBC,$(GLIBC_TARBALL)) \ $(call fetch_Optional,HSQLDB,$(HSQLDB_TARBALL)) \ $(call fetch_Optional,HUNSPELL,$(HUNSPELL_TARBALL)) \ + $(call fetch_Optional,HARFBUZZ,$(HARFBUZZ_TARBALL)) \ $(call fetch_Optional,HYPHEN,$(HYPHEN_TARBALL)) \ $(call fetch_Optional,ICU,$(ICU_TARBALL)) \ $(call fetch_Optional,JFREEREPORT,$(JFREEREPORT_FLOW_ENGINE_TARBALL)) \ diff --git a/RepositoryExternal.mk b/RepositoryExternal.mk index f3ee5dd..807150d 100644 --- a/RepositoryExternal.mk +++ b/RepositoryExternal.mk @@ -1186,6 +1186,39 @@ endef endif # SYSTEM_ICU +ifeq ($(ENABLE_HARFBUZZ),YES) +ifeq ($(SYSTEM_HARFBUZZ),YES) + +define gb_LinkTarget__use_harfbuzz +$(call gb_LinkTarget_set_include,$(1),\ + $$(INCLUDE) \ + $(HARFBUZZ_CFLAGS) \ +) +$(call gb_LinkTarget_add_libs,$(1),$(HARFBUZZ_LIBS)) + +endef + +else # SYSTEM_HARFBUZZ != YES + +$(eval $(call gb_Helper_register_static_libraries,PLAINLIBS, \ + harfbuzz \ +)) +define gb_LinkTarget__use_harfbuzz +$(call gb_LinkTarget_use_package,$(1),\ + harfbuzz \ +) +$(call gb_LinkTarget_use_static_libraries,$(1),\ + harfbuzz \ +) + +endef + +endif # SYSTEM_HARFBUZZ +else # ENABLE_HARFBUZZ != YES + +gb_LinkTarget__use_harfbuzz := + +endif # ENABLE_HARFBUZZ ifeq ($(DISABLE_OPENSSL),YES) diff --git a/RepositoryModule_host.mk b/RepositoryModule_host.mk index b9854f7..1b939f1 100644 --- a/RepositoryModule_host.mk +++ b/RepositoryModule_host.mk @@ -72,6 +72,7 @@ $(eval $(call gb_Module_add_moduledirs,libreoffice,\ framework \ $(call gb_Helper_optional,FREETYPE,freetype) \ $(call gb_Helper_optional,GRAPHITE,graphite) \ + $(call gb_Helper_optional,HARFBUZZ,harfbuzz) \ $(call gb_Helper_optional,DESKTOP,helpcompiler) \ $(call gb_Helper_optional,HELP,helpcontent2) \ $(call gb_Helper_optional,HSQLDB,hsqldb) \ diff --git a/config_host.mk.in b/config_host.mk.in index 4256fa7..ad33e7d 100644 --- a/config_host.mk.in +++ b/config_host.mk.in @@ -122,6 +122,7 @@ export ENABLE_GCONF=@ENABLE_GCONF@ export ENABLE_GIO=@ENABLE_GIO@ export ENABLE_GNOMEVFS=@ENABLE_GNOMEVFS@ export ENABLE_GRAPHITE=@ENABLE_GRAPHITE@ +export ENABLE_HARFBUZZ=@ENABLE_HARFBUZZ@ export ENABLE_GSTREAMER=@ENABLE_GSTREAMER@ export ENABLE_GSTREAMER_0_10=@ENABLE_GSTREAMER_0_10@ export ENABLE_GTK3=@ENABLE_GTK3@ @@ -196,6 +197,8 @@ export GPERF=@GPERF@ export GPERF=@GPERF@ export GRAPHITE_CFLAGS=$(gb_SPACE)@GRAPHITE_CFLAGS@ export GRAPHITE_LIBS=$(gb_SPACE)@GRAPHITE_LIBS@ +export HARFBUZZ_CFLAGS=$(gb_SPACE)@HARFBUZZ_CFLAGS@ +export HARFBUZZ_LIBS=$(gb_SPACE)@HARFBUZZ_LIBS@ @x_Cygwin@ export GREP=@WIN_GREP@ export GSSAPI_LIBS=@GSSAPI_LIBS@ export GSTREAMER_0_10_CFLAGS=$(gb_SPACE)@GSTREAMER_0_10_CFLAGS@ @@ -478,6 +481,7 @@ export SYSTEM_GENBRK=@SYSTEM_GENBRK@ export SYSTEM_GENCCODE=@SYSTEM_GENCCODE@ export SYSTEM_GENCMN=@SYSTEM_GENCMN@ export SYSTEM_GRAPHITE=@SYSTEM_GRAPHITE@ +export SYSTEM_HARFBUZZ=@SYSTEM_HARFBUZZ@ export SYSTEM_HSQLDB=@SYSTEM_HSQLDB@ export SYSTEM_HUNSPELL=@SYSTEM_HUNSPELL@ export SYSTEM_HYPH=@SYSTEM_HYPH@ diff --git a/config_host/config_harfbuzz.h.in b/config_host/config_harfbuzz.h.in new file mode 100644 index 000..b408f52 --- /dev/null +++ b/config_host/config_harfbuzz.h.in @@ -0,0 +1,6 @@ +#ifndef CONFIG_HARFBUZZ_H +#define CONFIG_HARFBUZZ_H
[Libreoffice-commits] core.git: vcl/generic
vcl/generic/glyphs/gcach_layout.cxx | 395 ++--
1 file changed, 379 insertions(+), 16 deletions(-)
New commits:
commit b760eff8cb65aba99b4527232140926bb4e11e82
Author: Khaled Hosny khaledho...@eglug.org
Date: Sat Apr 20 19:16:54 2013 +0200
Add support for using HarfBuzz instead of ICU LE
HarfBuzz is an up to date, actively maintained OpenType layout engine,
while the ICU LayoutEngine we use now has been unmaintained for a
while now, and existing users are encouraged to switch to HarfBuzz.
This is work in progress, text layout mostly works, but the handling
of combining marks is broken and needs further work, so it is kept
optional for now, with SAL_USE_HARFBUZZ env variable to enable it at
runtime.
Change-Id: I07e698f7486379bae68329771695cd94d6e561b5
Reviewed-on: https://gerrit.libreoffice.org/3518
Reviewed-by: Fridrich Strba fridr...@documentfoundation.org
Tested-by: Fridrich Strba fridr...@documentfoundation.org
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index ddf6d7c..1f9f3d0 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -17,6 +17,7 @@
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
+#include config_harfbuzz.h
#include gcach_ftyp.hxx
#include sallayout.hxx
#include salgdi.hxx
@@ -30,6 +31,10 @@
#include sal/alloca.h
#include rtl/instance.hxx
+#if ENABLE_HARFBUZZ
+#include harfbuzz/hb-icu.h
+#include harfbuzz/hb-ot.h
+#endif
#include layout/LayoutEngine.h
#include layout/LEFontInstance.h
#include layout/LELanguages.h
@@ -87,6 +92,371 @@ void ServerFontLayout::AdjustLayout( ImplLayoutArgs rArgs )
}
// ===
+
+static bool lcl_CharIsJoiner(sal_Unicode cChar)
+{
+return ((cChar == 0x200C) || (cChar == 0x200D));
+}
+
+static bool needPreviousCode(sal_Unicode cChar)
+{
+return lcl_CharIsJoiner(cChar) || U16_IS_LEAD(cChar);
+}
+
+static bool needNextCode(sal_Unicode cChar)
+{
+return lcl_CharIsJoiner(cChar) || U16_IS_TRAIL(cChar);
+}
+
+#if ENABLE_HARFBUZZ
+static hb_blob_t *getFontTable(hb_face_t* /*face*/, hb_tag_t nTableTag, void*
userData)
+{
+char pTagName[5];
+pTagName[0] = (char)(nTableTag 24);
+pTagName[1] = (char)(nTableTag 16);
+pTagName[2] = (char)(nTableTag 8);
+pTagName[3] = (char)(nTableTag);
+pTagName[4] = 0;
+
+ServerFont* rFont = (ServerFont*) userData;
+sal_uLong nLength;
+const unsigned char* pBuffer = rFont-GetTable(pTagName, nLength);
+
+hb_blob_t* pBlob = NULL;
+if (pBuffer != NULL)
+pBlob = hb_blob_create((const char*) pBuffer, nLength,
HB_MEMORY_MODE_WRITABLE, (void*) pBuffer, free);
+
+return pBlob;
+}
+
+static hb_bool_t getFontGlyph(hb_font_t* /*font*/, void* fontData,
+hb_codepoint_t ch, hb_codepoint_t vs,
+hb_codepoint_t* nGlyphIndex,
+void* /*userData*/)
+{
+ServerFont* rFont = (ServerFont*) fontData;
+*nGlyphIndex = 0;
+
+if (vs)
+*nGlyphIndex = rFont-GetRawGlyphIndex(ch /*, vs*/); // XXX handle
variation selectors
+
+if (*nGlyphIndex == 0)
+*nGlyphIndex = rFont-GetRawGlyphIndex(ch);
+
+return *nGlyphIndex != 0;
+}
+
+static hb_position_t getGlyphAdvanceH(hb_font_t* /*font*/, void* fontData,
+hb_codepoint_t nGlyphIndex,
+void* /*userData*/)
+{
+ServerFont* rFont = (ServerFont*) fontData;
+const GlyphMetric rGM = rFont-GetGlyphMetric(nGlyphIndex);
+return rGM.GetCharWidth();
+}
+
+static hb_position_t getGlyphAdvanceV(hb_font_t* /*font*/, void* /*fontData*/,
+hb_codepoint_t /*nGlyphIndex*/,
+void* /*userData*/)
+{
+// XXX: vertical metrics
+return 0;
+}
+
+static hb_bool_t getGlyphOriginH(hb_font_t* /*font*/, void* /*fontData*/,
+hb_codepoint_t /*nGlyphIndex*/,
+hb_position_t* /*x*/, hb_position_t* /*y*/,
+void* /*userData*/)
+{
+// the horizontal origin is always (0, 0)
+return true;
+}
+
+static hb_bool_t getGlyphOriginV(hb_font_t* /*font*/, void* /*fontData*/,
+hb_codepoint_t /*nGlyphIndex*/,
+hb_position_t* /*x*/, hb_position_t* /*y*/,
+void* /*userData*/)
+{
+// XXX: vertical origin
+return true;
+}
+
+static hb_position_t getGlyphKerningH(hb_font_t* /*font*/, void* fontData,
+hb_codepoint_t nGlyphIndex1, hb_codepoint_t nGlyphIndex2,
+void* /*userData*/)
+{
+// This callback is for old style 'kern' table, GPOS kerning is handled by
HarfBuzz directly
+
+// XXX: there is ServerFont::GetKernPairs() but it does many smart things
+// that I'm not sure about, so I'm using FreeType directly
+// P.S. if we decided not to use ServerFont::GetKernPairs() then it and all
+// other implementattions should be removed, don't seem to be used
+// anywhere.
+
+ServerFont* rFont = (ServerFont*) fontData
[Libreoffice-commits] core.git: vcl/generic
vcl/generic/glyphs/gcach_layout.cxx | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
New commits:
commit 9d4395540a10916d471579618d7bf3b60cd49140
Author: Khaled Hosny khaledho...@eglug.org
Date: Tue Apr 23 12:39:07 2013 +0200
Fix glyph width calculation in HarfBuzz
Make sure everything is using 16.16 fixed point values consistently.
Change-Id: Icdcd94775d3860d57bb446a3f237c31e35e0710a
Reviewed-on: https://gerrit.libreoffice.org/3573
Reviewed-by: Fridrich Strba fridr...@documentfoundation.org
Tested-by: Fridrich Strba fridr...@documentfoundation.org
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index 1f9f3d0..ca40e9d 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -152,7 +152,7 @@ static hb_position_t getGlyphAdvanceH(hb_font_t* /*font*/,
void* fontData,
{
ServerFont* rFont = (ServerFont*) fontData;
const GlyphMetric rGM = rFont-GetGlyphMetric(nGlyphIndex);
-return rGM.GetCharWidth();
+return rGM.GetCharWidth() 6;
}
static hb_position_t getGlyphAdvanceV(hb_font_t* /*font*/, void* /*fontData*/,
@@ -415,10 +415,10 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
if (hb_ot_layout_get_glyph_class(maHbFace, nGlyphIndex) ==
HB_OT_LAYOUT_GLYPH_CLASS_MARK)
nGlyphFlags |= GlyphItem::IS_DIACRITIC;
-aHbPositions[i].x_offset /= 64;
-aHbPositions[i].y_offset /= 64;
-aHbPositions[i].x_advance /= 64;
-aHbPositions[i].y_advance /= 64;
+aHbPositions[i].x_offset = aHbPositions[i].x_offset 6;
+aHbPositions[i].y_offset = aHbPositions[i].y_offset 6;
+aHbPositions[i].x_advance = aHbPositions[i].x_advance 6;
+aHbPositions[i].y_advance = aHbPositions[i].y_advance 6;
aNewPos = Point(aNewPos.X() + aHbPositions[i].x_offset,
aNewPos.Y() - aHbPositions[i].y_offset);
@@ -429,7 +429,7 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
// instead of nGlyphWidth above, and leave mnNewWidth alone
// (whatever it is meant for)
if (i + 1 nRunGlyphCount)
-aGI.mnNewWidth = nGlyphWidth + (aHbPositions[i + 1].x_offset /
64);
+aGI.mnNewWidth = nGlyphWidth + (aHbPositions[i + 1].x_offset
6);
rLayout.AppendGlyph(aGI);
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Re: [PATCH] fdo#35320 A fix for Arabic justification problem caused by k...
On Sun, Apr 28, 2013 at 06:04:04AM +, Ahmad Harthi (via Code Review) wrote: Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/3644 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/44/3644/1 fdo#35320 A fix for Arabic justification problem caused by kashidas diff --git a/vcl/source/gdi/sallayout.cxx b/vcl/source/gdi/sallayout.cxx index 9d315e3..d4696c7 100644 --- a/vcl/source/gdi/sallayout.cxx +++ b/vcl/source/gdi/sallayout.cxx @@ -1274,7 +1274,7 @@ // calculate gap, ignore if too small int nGapWidth = pG-mnNewWidth - pG-mnOrigWidth; // worst case is one kashida even for mini-gaps -if( 3 * nGapWidth nKashidaWidth ) +if( nGapWidth nKashidaWidth ) continue; nKashidaCount = 0; Can we have some explanation what the patch is doing? Neither the commit message nor the bugzilla issue explain the fix. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: 9 commits - vcl/generic vcl/inc
vcl/generic/glyphs/gcach_layout.cxx | 280 +++-
vcl/inc/generic/glyphcache.hxx | 11 +
vcl/inc/sallayout.hxx |3
3 files changed, 198 insertions(+), 96 deletions(-)
New commits:
commit c559b13b80ab4c8ca4e6ca713bce388ea650e02c
Author: Khaled Hosny khaledho...@eglug.org
Date: Sun Apr 28 15:56:26 2013 +0200
[harfbuzz] Re-enable text justification
It turned out that ApplyDXArray() is need to apply advance width
adjustments after justification, so we can't just bypass it.
So I just copied GenericSalLayout::ApplyDXArray() and stripped it of
ICUism so it does not break with HarfBuzz, but I had to make
m_GlyphItems non-private, so I'm not sure this is the right approach.
Change-Id: I66d647c3590fdf912c39d0cf23ac72bcc7ca72c9
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index f147ab2..abd1ab8 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -106,13 +106,85 @@ void ServerFontLayout::AdjustLayout( ImplLayoutArgs
rArgs )
}
}
+// apply adjustments to glyph advances, e.g. as a result of justification.
void ServerFontLayout::ApplyDXArray(ImplLayoutArgs rArgs)
{
-// No idea what issue ApplyDXArray() was supposed to fix, but whatever
-// GenericSalLayout::ApplyDXArray() does it just breaks our perfectly
-// positioned text.
-if (!bUseHarfBuzz)
+if (bUseHarfBuzz)
+{
+if (m_GlyphItems.empty())
+return;
+
+// determine cluster boundaries and x base offset
+const int nCharCount = rArgs.mnEndCharPos - rArgs.mnMinCharPos;
+int* pLogCluster = (int*)alloca(nCharCount * sizeof(int));
+size_t i;
+int n,p;
+long nBasePointX = -1;
+if (mnLayoutFlags SAL_LAYOUT_FOR_FALLBACK)
+nBasePointX = 0;
+for (p = 0; p nCharCount; ++p)
+pLogCluster[p] = -1;
+
+for (i = 0; i m_GlyphItems.size(); ++i)
+{
+n = m_GlyphItems[i].mnCharPos - rArgs.mnMinCharPos;
+if ((n 0) || (nCharCount = n))
+continue;
+if (pLogCluster[n] 0)
+pLogCluster[n] = i;
+if (nBasePointX 0)
+nBasePointX = m_GlyphItems[i].maLinearPos.X();
+}
+// retarget unresolved pLogCluster[n] to a glyph inside the cluster
+// TODO: better do it while the deleted-glyph markers are still there
+for (n = 0; n nCharCount; ++n)
+if ((p = pLogCluster[0]) = 0)
+break;
+if (n = nCharCount)
+return;
+for (n = 0; n nCharCount; ++n)
+{
+if (pLogCluster[n] 0)
+pLogCluster[n] = p;
+else
+p = pLogCluster[n];
+}
+
+// calculate adjusted cluster widths
+sal_Int32* pNewGlyphWidths = (sal_Int32*)alloca(m_GlyphItems.size() *
sizeof(sal_Int32));
+for (i = 0; i m_GlyphItems.size(); ++i)
+pNewGlyphWidths[i] = 0;
+
+bool bRTL;
+for (int nCharPos = p = -1; rArgs.GetNextPos(nCharPos, bRTL); )
+{
+n = nCharPos - rArgs.mnMinCharPos;
+if ((n 0) || (nCharCount = n)) continue;
+
+if (pLogCluster[n] = 0)
+p = pLogCluster[n];
+if (p = 0)
+{
+long nDelta = rArgs.mpDXArray[n];
+if(n 0)
+nDelta -= rArgs.mpDXArray[n - 1];
+pNewGlyphWidths[p] += nDelta * mnUnitsPerPixel;
+}
+}
+
+// move cluster positions using the adjusted widths
+long nDelta = 0;
+for (i = 0; i m_GlyphItems.size(); ++i)
+{
+nDelta += pNewGlyphWidths[i] - m_GlyphItems[i].mnNewWidth;
+m_GlyphItems[i].mnNewWidth = pNewGlyphWidths[i];
+m_GlyphItems[i].maLinearPos.X() += nDelta;
+}
+}
+else
+{
GenericSalLayout::ApplyDXArray(rArgs);
+}
}
// ===
diff --git a/vcl/inc/sallayout.hxx b/vcl/inc/sallayout.hxx
index ad6cd94..5d99acb 100644
--- a/vcl/inc/sallayout.hxx
+++ b/vcl/inc/sallayout.hxx
@@ -367,8 +367,9 @@ protected:
boolGetCharWidths( sal_Int32* pCharWidths ) const;
-private:
GlyphVector m_GlyphItems;
+
+private:
mutable Point maBasePoint;
// enforce proper copy semantic
commit ca0b580e2a21999d75bcd39ae5b6f81e9e42897b
Author: Khaled Hosny khaledho...@eglug.org
Date: Sun Apr 28 23:06:45 2013 +0200
[harfbuzz] Fix shaping across text runs
The 3rd parameter to hb_buffer_add_utf() should be the length of the
whole text not the current run, so that HarfBuzz can take the context
into account when shaping.
Change-Id: I9e4e928d40078c3e3667cfdb6d8f24bf6e58263d
diff --git a/vcl/generic/glyphs
[Libreoffice-commits] core.git: vcl/generic
vcl/generic/glyphs/gcach_layout.cxx |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 3719396649c8c944727f89c517a8191cd37b2499 Author: Khaled Hosny khaledho...@eglug.org Date: Mon Apr 29 22:13:44 2013 +0200 [harfbuzz] Don't crash when closing LibreOffice We shouldn't be trying to free the font table buffer when destroying the blob, so pass NULL for destroy function instead of free(), and also use HB_MEMORY_MODE_READONLY just to be safe. Change-Id: I85b5a575249b4efc0f5799db205ee17cbeb66d22 diff --git a/vcl/generic/glyphs/gcach_layout.cxx b/vcl/generic/glyphs/gcach_layout.cxx index abd1ab8..5fea884 100644 --- a/vcl/generic/glyphs/gcach_layout.cxx +++ b/vcl/generic/glyphs/gcach_layout.cxx @@ -220,7 +220,7 @@ static hb_blob_t *getFontTable(hb_face_t* /*face*/, hb_tag_t nTableTag, void* pU hb_blob_t* pBlob = NULL; if (pBuffer != NULL) -pBlob = hb_blob_create((const char*) pBuffer, nLength, HB_MEMORY_MODE_WRITABLE, (void*) pBuffer, free); +pBlob = hb_blob_create((const char*) pBuffer, nLength, HB_MEMORY_MODE_READONLY, (void*) pBuffer, NULL); return pBlob; } ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: vcl/generic
vcl/generic/glyphs/gcach_layout.cxx | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
New commits:
commit 84a8f817e174855ef72f0bafc734847690c5d736
Author: Khaled Hosny khaledho...@eglug.org
Date: Tue Apr 30 17:16:17 2013 +0200
[harfbuzz] Simplify cluster detection
Change-Id: I48c11fad175fe40f48baaa47238f6087b91e6a37
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index 5fea884..a849d9d 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -474,11 +474,9 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
hb_glyph_info_t *pHbGlyphInfos = hb_buffer_get_glyph_infos(pHbBuffer,
NULL);
hb_glyph_position_t *pHbPositions =
hb_buffer_get_glyph_positions(pHbBuffer, NULL);
-int32_t nLastCluster = -1;
for (int i = 0; i nRunGlyphCount; ++i) {
int32_t nGlyphIndex = pHbGlyphInfos[i].codepoint;
-int32_t nCluster = pHbGlyphInfos[i].cluster;
-int32_t nCharPos = nCluster;
+int32_t nCharPos = pHbGlyphInfos[i].cluster;
// if needed request glyph fallback by updating LayoutArgs
if (!nGlyphIndex)
@@ -500,16 +498,14 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
continue;
}
+bool bInCluster = false;
+if (i 0 pHbGlyphInfos[i].cluster == pHbGlyphInfos[i -
1].cluster)
+bInCluster = true;
+
long nGlyphFlags = 0;
if (bRightToLeft)
nGlyphFlags |= GlyphItem::IS_RTL_GLYPH;
-// what is this for?
-// XXX: rtl clusters
-bool bInCluster = false;
-if (nCluster == nLastCluster)
-bInCluster = true;
-nLastCluster = nCluster;
if (bInCluster)
nGlyphFlags |= GlyphItem::IS_IN_CLUSTER;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: 2 commits - vcl/generic
vcl/generic/glyphs/gcach_layout.cxx | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
New commits:
commit 76abedd3bd1c91cac9b239f746243df00a58d060
Author: Khaled Hosny khaledho...@eglug.org
Date: Thu May 2 06:19:38 2013 +0200
[harfbuzz] Fix shaping across text runs, take 2
The 3rd parameter of hb_buffer_add_utf() should be the length of the
whole text not the current run, so that HarfBuzz can take the context
into account when shaping.
Change-Id: I369deb27176cbb136de12872b8a70453d5721bea
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index d562d3b..ad93b9a 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -465,7 +465,7 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
hb_buffer_set_direction(pHbBuffer, bRightToLeft ? HB_DIRECTION_RTL:
HB_DIRECTION_LTR);
hb_buffer_set_script(pHbBuffer, hb_icu_script_to_script(eScriptCode));
hb_buffer_set_language(pHbBuffer,
hb_language_from_string(sLanguage.getStr(), -1));
-hb_buffer_add_utf16(pHbBuffer, rArgs.mpStr, nRunLen, nMinRunPos,
nRunLen);
+hb_buffer_add_utf16(pHbBuffer, rArgs.mpStr, rArgs.mnLength,
nMinRunPos, nRunLen);
hb_shape(pHbFont, pHbBuffer, NULL, 0);
int nRunGlyphCount = hb_buffer_get_length(pHbBuffer);
@@ -480,15 +480,7 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
if (!nGlyphIndex)
{
if (nCharPos = 0)
-{
rArgs.NeedFallback(nCharPos, bRightToLeft);
-// XXX: do we need this? HarfBuzz can take context into
-// account when shaping
-if ((nCharPos 0)
needPreviousCode(rArgs.mpStr[nCharPos-1]))
-rArgs.NeedFallback(nCharPos-1, bRightToLeft);
-else if ((nCharPos + 1 nEndRunPos)
needNextCode(rArgs.mpStr[nCharPos+1]))
-rArgs.NeedFallback(nCharPos+1, bRightToLeft);
-}
if (SAL_LAYOUT_FOR_FALLBACK rArgs.mnFlags)
continue;
commit 69a120ccc6a8afdb239912f9b4fbbc123e69d4ca
Author: Khaled Hosny khaledho...@eglug.org
Date: Thu May 2 06:13:58 2013 +0200
Revert [harfbuzz] Fix shaping across text runs
This reverts commit ca0b580e2a21999d75bcd39ae5b6f81e9e42897b.
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index a849d9d..d562d3b 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -422,10 +422,8 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
((uint64_t) aFtFace-size-metrics.y_scale * (uint64_t)
fUnitsPerEM) 16);
hb_font_set_ppem(pHbFont, aFtFace-size-metrics.x_ppem,
aFtFace-size-metrics.y_ppem);
-int nTextLen = rArgs.mnEndCharPos - rArgs.mnMinCharPos;
-
// allocate temporary arrays, note: round to even
-int nGlyphCapacity = (3 * nTextLen | 15) + 1;
+int nGlyphCapacity = (3 * (rArgs.mnEndCharPos - rArgs.mnMinCharPos) | 15)
+ 1;
rLayout.Reserve(nGlyphCapacity);
@@ -467,7 +465,7 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
hb_buffer_set_direction(pHbBuffer, bRightToLeft ? HB_DIRECTION_RTL:
HB_DIRECTION_LTR);
hb_buffer_set_script(pHbBuffer, hb_icu_script_to_script(eScriptCode));
hb_buffer_set_language(pHbBuffer,
hb_language_from_string(sLanguage.getStr(), -1));
-hb_buffer_add_utf16(pHbBuffer, rArgs.mpStr, nTextLen, nMinRunPos,
nRunLen);
+hb_buffer_add_utf16(pHbBuffer, rArgs.mpStr, nRunLen, nMinRunPos,
nRunLen);
hb_shape(pHbFont, pHbBuffer, NULL, 0);
int nRunGlyphCount = hb_buffer_get_length(pHbBuffer);
@@ -484,14 +482,12 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
if (nCharPos = 0)
{
rArgs.NeedFallback(nCharPos, bRightToLeft);
-#if 0
// XXX: do we need this? HarfBuzz can take context into
// account when shaping
if ((nCharPos 0)
needPreviousCode(rArgs.mpStr[nCharPos-1]))
rArgs.NeedFallback(nCharPos-1, bRightToLeft);
else if ((nCharPos + 1 nEndRunPos)
needNextCode(rArgs.mpStr[nCharPos+1]))
rArgs.NeedFallback(nCharPos+1, bRightToLeft);
-#endif
}
if (SAL_LAYOUT_FOR_FALLBACK rArgs.mnFlags)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: vcl/generic
vcl/generic/glyphs/gcach_layout.cxx | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
New commits:
commit 405dc9d241f617853c77e60b0b0d41c36b5af33d
Author: Khaled Hosny khaledho...@eglug.org
Date: Fri May 3 23:39:19 2013 +0200
[harfbuzz] Fix placement of multi-glyph clusters
Calculate the delta based on the whole cluster width no just the first
glyph.
This whole ApplyDXArray() business is completely flawed, it is just
trying to second guess information we already had, and then workaround
all bugs it is introducing.
Change-Id: I5f719d7addcb89c9d5662b48ca7cf55cd388b41e
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index fa04dca..fab66ac 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -176,7 +176,22 @@ void ServerFontLayout::ApplyDXArray(ImplLayoutArgs rArgs)
long nDelta = 0;
for (i = 0; i m_GlyphItems.size(); ++i)
{
-nDelta += pNewGlyphWidths[i] - m_GlyphItems[i].mnNewWidth;
+if (m_GlyphItems[i].IsClusterStart())
+{
+// calculate original and adjusted cluster width
+int nOldClusterWidth = m_GlyphItems[i].mnNewWidth;
+int nNewClusterWidth = pNewGlyphWidths[i];
+size_t j;
+for (j = i; ++j m_GlyphItems.size(); )
+{
+if (m_GlyphItems[j].IsClusterStart())
+break;
+if (!m_GlyphItems[j].IsDiacritic()) // #i99367# ignore
diacritics
+nOldClusterWidth += m_GlyphItems[j].mnNewWidth;
+nNewClusterWidth += pNewGlyphWidths[j];
+}
+nDelta += nNewClusterWidth - nOldClusterWidth;
+}
m_GlyphItems[i].mnNewWidth = pNewGlyphWidths[i];
m_GlyphItems[i].maLinearPos.X() += nDelta;
}
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Use of markup in .ui strings
Hi all, Commit 8274df8 seems to have introduced the use of markup in .ui files to set text in bold, however this is not really a good idea l10n-wise as it is very error-prone, Gnome is actually moving away from using markup in translatable strings[1], which I think something LibreOffice should do. Glade/.ui files support attributes which can be used to set text attributes that affect the while string, while markup is reserved for the rare case where only part of the string need to be marked up (though it is still not a very good idea). Regards, Khaled [1] https://live.gnome.org/GnomeGoals/RemoveMarkupInMessages ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Use of markup in .ui strings
On Thu, Oct 25, 2012 at 03:33:34PM +0100, Caolán McNamara wrote: On Mon, 2012-10-22 at 14:14 +0100, Caolán McNamara wrote: On Sun, 2012-10-21 at 00:47 +0200, Khaled Hosny wrote: Hi all, Commit 8274df8 seems to have introduced the use of markup in .ui files to set text in bold, however this is not really a good idea l10n-wise as it is very error-prone... We can make that change easily enough, ... I'll change things around later this week to use attributes instead, Done as http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3fb6d227c77198aa0b70d6f5260ff239f5d692c Thank you! I knew by the time I'd figure it out you would have been done with it :) Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features, hacky patch
On Fri, Sep 07, 2012 at 06:43:26PM +0200, Khaled Hosny wrote: On Fri, Sep 07, 2012 at 05:18:46PM +0100, Caolán McNamara wrote: On Sat, 2012-07-21 at 18:20 +0200, Khaled Hosny wrote: Here is a very crude, WIP patch. It adds --enable-harfbuzz configure option, plus some (very broken) harfbuzz layout code, but I can't get the ENABLE_HARFBUZZ to propagate in and thus can't do any testing because the code is never compiled. I appreciate any insights on how to get this to work. You need to put harfbuzz in the gb_Library_use_externals section of Library_vcl.mk (or whichever is the right .mk file in vcl) It would be nice to get this feature in as a compile time option for experimenting with. I’ve some code that more or less works (as in displaying some text), but it crashes like hell, I'm yet to figure out what is going on (I think I've to override more members of ServerFontLayout to make things saner). Realizing that I might not get around fixing basic issues with HarfBuzz integration anytime soon, I'm attaching preliminary patches I've for any one interested in them. So far LTR text works fine, RTL horizontal offsets (e.g. kerning) seems to be applied in the wrong direction, probably the same old issue with ICU that we band aided a while ago, which seems to be because of (Generic)SalLayout::AdjustLayout and ::Justify doing tricks with glyph advances and offsets (I've hard time wrapping my head around all this SalLayout, GenericSalLayout, MultiSalLayout etc. we really should consolidate this stuff now that we have only one shaping path on *nix). Regards, Khaled From 6a05198fcf86af5d8898430077705920b71ff64b Mon Sep 17 00:00:00 2001 From: Khaled Hosny khaledho...@eglug.org Date: Sun, 28 Oct 2012 01:31:11 +0200 Subject: [PATCH 1/2] Add HarfBuzz support to the build system Not used yet, and no support for local build either. Change-Id: I7121fbe66e57eaa6be0e58451acf9a2ea7b50f59 --- RepositoryExternal.mk | 23 +++ config_host.mk.in |3 +++ configure.ac | 27 +++ vcl/Library_vcl.mk|9 + 4 files changed, 62 insertions(+) diff --git a/RepositoryExternal.mk b/RepositoryExternal.mk index e08beec..22aa2a0 100644 --- a/RepositoryExternal.mk +++ b/RepositoryExternal.mk @@ -1498,6 +1498,29 @@ gb_LinkTarget__use_pixbuf := endif # SYSTEM_GDKPIXBUF +ifeq ($(ENABLE_HARFBUZZ),TRUE) + +define gb_LinkTarget__use_harfbuzz +$(call gb_LinkTarget_set_include,$(1),\ + $$(INCLUDE) \ + $(HARFBUZZ_CFLAGS) \ +) + +$(call gb_LinkTarget_add_libs,$(1),\ + $(HARFBUZZ_LIBS) \ +) + +endef + +else # !ENABLE_HARFBUZZ + +define gb_LinkTarget__use_harfbuzz + +endef + +endif # ENABLE_HARFBUZZ + + ifeq ($(SYSTEM_DB),YES) define gb_LinkTarget__use_berkeleydb diff --git a/config_host.mk.in b/config_host.mk.in index 9a5fbfd..8322624 100644 --- a/config_host.mk.in +++ b/config_host.mk.in @@ -145,6 +145,7 @@ export ENABLE_GSTREAMER_0_10=@ENABLE_GSTREAMER_0_10@ export ENABLE_GTK3=@ENABLE_GTK3@ export ENABLE_GTK=@ENABLE_GTK@ export ENABLE_GTK_PRINT=@ENABLE_GTK_PRINT@ +export ENABLE_HARFBUZZ=@ENABLE_HARFBUZZ@ export ENABLE_HEADLESS=@ENABLE_HEADLESS@ export ENABLE_TDEAB=@ENABLE_TDEAB@ export ENABLE_TDE=@ENABLE_TDE@ @@ -240,6 +241,8 @@ export GUIBASE=@GUIBASE@ export GUIBASE_FOR_BUILD=@GUIBASE_FOR_BUILD@ export GUI_FOR_BUILD=@GUI_FOR_BUILD@ export GXX_INCLUDE_PATH=@GXX_INCLUDE_PATH@ +export HARFBUZZ_CFLAGS=@HARFBUZZ_CFLAGS@ +export HARFBUZZ_LIBS=@HARFBUZZ_LIBS@ export HAVE_CXX0X=@HAVE_CXX0X@ export HAVE_GCC_AVX=@HAVE_GCC_AVX@ export HAVE_GCC_BUILTIN_ATOMIC=@HAVE_GCC_BUILTIN_ATOMIC@ diff --git a/configure.ac b/configure.ac index 6f654a2..a260cc4 100644 --- a/configure.ac +++ b/configure.ac @@ -886,6 +886,11 @@ AC_ARG_ENABLE(gio, [Determines whether to use the GIO support.]), ,enable_gio=no) +AC_ARG_ENABLE(harfbuzz, +AS_HELP_STRING([--enable-harfbuzz], +[Determines whether to use HarfBuzz text layout engine.]), +,enable_harfbuzz=no) + AC_ARG_ENABLE(telepathy, AS_HELP_STRING([--enable-telepathy], [Determines whether to enable Telepathy for collaboration.]), @@ -9582,6 +9587,28 @@ AC_SUBST([GTK_PRINT_LIBS]) dnl === +dnl Check whether the HarfBuzz libraries are available. +dnl === + +ENABLE_HARFBUZZ= +HARFBUZZ_CFLAGS= +HARFBUZZ_LIBS= + +AC_MSG_CHECKING([whether to enable HarfBuzz support]) +if test $_os != WINNT -a $_os != Darwin -a $enable_harfbuzz = yes; then +ENABLE_HARFBUZZ=TRUE +AC_MSG_RESULT([yes]) +PKG_CHECK_MODULES( HARFBUZZ, harfbuzz = 0.9.3 ) +else +AC_MSG_RESULT([no]) +fi + +AC_SUBST(ENABLE_HARFBUZZ) +AC_SUBST(HARFBUZZ_CFLAGS) +AC_SUBST(HARFBUZZ_LIBS) + + +dnl === dnl Check whether the Telepathy libraries are available. dnl
Re: Modern font features, hacky patch
On Sun, Oct 28, 2012 at 09:37:05AM +0100, Matúš Kukan wrote: On 28 October 2012 02:59, Khaled Hosny khaledho...@eglug.org wrote: Realizing that I might not get around fixing basic issues with HarfBuzz integration anytime soon, I'm attaching preliminary patches I've for any one interested in them. You set ENABLE_HARFBUZZ as TRUE / empty but use in vcl: ifneq ($(ENABLE_HARFBUZZ),NO) - always true Thank you, I copied the librsvg conditional below it blindly :) A fixed patch is attached. Regards, Khaled From 987dc147c6e86b213ddb2f914414decafe09abe4 Mon Sep 17 00:00:00 2001 From: Khaled Hosny khaledho...@eglug.org Date: Sun, 28 Oct 2012 01:31:11 +0200 Subject: [PATCH 1/2] Add HarfBuzz support to the build system Not used yet, and no support for local build either. Change-Id: I7121fbe66e57eaa6be0e58451acf9a2ea7b50f59 --- RepositoryExternal.mk | 23 +++ config_host.mk.in |3 +++ configure.ac | 27 +++ vcl/Library_vcl.mk|9 + 4 files changed, 62 insertions(+) diff --git a/RepositoryExternal.mk b/RepositoryExternal.mk index ca87908..c5188a7 100644 --- a/RepositoryExternal.mk +++ b/RepositoryExternal.mk @@ -1530,6 +1530,29 @@ gb_LinkTarget__use_pixbuf := endif # SYSTEM_GDKPIXBUF +ifeq ($(ENABLE_HARFBUZZ),TRUE) + +define gb_LinkTarget__use_harfbuzz +$(call gb_LinkTarget_set_include,$(1),\ + $$(INCLUDE) \ + $(HARFBUZZ_CFLAGS) \ +) + +$(call gb_LinkTarget_add_libs,$(1),\ + $(HARFBUZZ_LIBS) \ +) + +endef + +else # !ENABLE_HARFBUZZ + +define gb_LinkTarget__use_harfbuzz + +endef + +endif # ENABLE_HARFBUZZ + + ifeq ($(SYSTEM_DB),YES) define gb_LinkTarget__use_berkeleydb diff --git a/config_host.mk.in b/config_host.mk.in index 0317bef..00d2bcb 100644 --- a/config_host.mk.in +++ b/config_host.mk.in @@ -143,6 +143,7 @@ export ENABLE_GSTREAMER_0_10=@ENABLE_GSTREAMER_0_10@ export ENABLE_GTK3=@ENABLE_GTK3@ export ENABLE_GTK=@ENABLE_GTK@ export ENABLE_GTK_PRINT=@ENABLE_GTK_PRINT@ +export ENABLE_HARFBUZZ=@ENABLE_HARFBUZZ@ export ENABLE_HEADLESS=@ENABLE_HEADLESS@ export ENABLE_TDEAB=@ENABLE_TDEAB@ export ENABLE_TDE=@ENABLE_TDE@ @@ -237,6 +238,8 @@ export GUIBASE=@GUIBASE@ export GUIBASE_FOR_BUILD=@GUIBASE_FOR_BUILD@ export GUI_FOR_BUILD=@GUI_FOR_BUILD@ export GXX_INCLUDE_PATH=@GXX_INCLUDE_PATH@ +export HARFBUZZ_CFLAGS=@HARFBUZZ_CFLAGS@ +export HARFBUZZ_LIBS=@HARFBUZZ_LIBS@ export HAVE_CXX0X=@HAVE_CXX0X@ export HAVE_GCC_AVX=@HAVE_GCC_AVX@ export HAVE_GCC_BUILTIN_ATOMIC=@HAVE_GCC_BUILTIN_ATOMIC@ diff --git a/configure.ac b/configure.ac index 9a9689a..d2e81a9 100644 --- a/configure.ac +++ b/configure.ac @@ -885,6 +885,11 @@ AC_ARG_ENABLE(gio, [Determines whether to use the GIO support.]), ,enable_gio=no) +AC_ARG_ENABLE(harfbuzz, +AS_HELP_STRING([--enable-harfbuzz], +[Determines whether to use HarfBuzz text layout engine.]), +,enable_harfbuzz=no) + AC_ARG_ENABLE(telepathy, AS_HELP_STRING([--enable-telepathy], [Determines whether to enable Telepathy for collaboration.]), @@ -9595,6 +9600,28 @@ AC_SUBST([GTK_PRINT_LIBS]) dnl === +dnl Check whether the HarfBuzz libraries are available. +dnl === + +ENABLE_HARFBUZZ= +HARFBUZZ_CFLAGS= +HARFBUZZ_LIBS= + +AC_MSG_CHECKING([whether to enable HarfBuzz support]) +if test $_os != WINNT -a $_os != Darwin -a $enable_harfbuzz = yes; then +ENABLE_HARFBUZZ=TRUE +AC_MSG_RESULT([yes]) +PKG_CHECK_MODULES( HARFBUZZ, harfbuzz = 0.9.3 ) +else +AC_MSG_RESULT([no]) +fi + +AC_SUBST(ENABLE_HARFBUZZ) +AC_SUBST(HARFBUZZ_CFLAGS) +AC_SUBST(HARFBUZZ_LIBS) + + +dnl === dnl Check whether the Telepathy libraries are available. dnl === diff --git a/vcl/Library_vcl.mk b/vcl/Library_vcl.mk index 1ff3339..c6e5256 100644 --- a/vcl/Library_vcl.mk +++ b/vcl/Library_vcl.mk @@ -315,6 +315,15 @@ $(eval $(call gb_Library_use_external,vcl,graphite)) endif +ifeq ($(ENABLE_HARFBUZZ),TRUE) +$(eval $(call gb_Library_add_defs,vcl,\ +-DENABLE_HARFBUZZ \ +)) + +$(eval $(call gb_Library_use_externals,vcl,harfbuzz)) + +endif + ifneq ($(ENABLE_LIBRSVG),NO) $(eval $(call gb_Library_add_exception_objects,vcl,\ vcl/source/components/rasterizer_rsvg \ -- 1.7.9.5 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: vcl/generic
vcl/generic/glyphs/gcach_layout.cxx |9 +
1 file changed, 9 insertions(+)
New commits:
commit 784cd10c31e4378e5b9d03791154e01d23867120
Author: Khaled Hosny khaledho...@eglug.org
Date: Sun May 5 21:10:52 2013 +0200
[harfbuzz] Fix vertical text layout
Fixed in the sense that it works exactly like the non-HarfBuzz case,
but that is already a bit broken. Need to get rid if the little OpenType
layout engine in ServerFont::ApplyGSUB() and use HarfBuzz's vertical
text layout capabilities.
Change-Id: I32abe385575bd5d1b66e573dfe2fc7f412d02254
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index fab66ac..f7b6907 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -501,6 +501,15 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
continue;
}
+// apply vertical flags and glyph substitution
+// XXX: Use HB_DIRECTION_TTB above and apply whatever flags magic
+// FixupGlyphIndex() is doing, minus the GSUB part.
+if (nCharPos = 0)
+{
+sal_UCS4 aChar = rArgs.mpStr[nCharPos];
+nGlyphIndex = rFont.FixupGlyphIndex(nGlyphIndex, aChar);
+}
+
bool bInCluster = false;
if (i 0 pHbGlyphInfos[i].cluster == pHbGlyphInfos[i -
1].cluster)
bInCluster = true;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: 2 commits - vcl/generic vcl/inc vcl/source
vcl/generic/glyphs/gcach_ftyp.cxx | 29 +++--
vcl/generic/glyphs/gcach_layout.cxx |8 +---
vcl/inc/generic/glyphcache.hxx |2 +-
vcl/source/gdi/sallayout.cxx|5 -
4 files changed, 21 insertions(+), 23 deletions(-)
New commits:
commit 9a8f125fa7e63b829471a6722dae3006bb1f57d2
Author: Khaled Hosny khaledho...@eglug.org
Date: Mon May 6 01:40:06 2013 +0200
[harfbuzz] Support Unicode variation selectors
Change-Id: I8c56f45505327857613c39b28da3ae7cc3ad201c
diff --git a/vcl/generic/glyphs/gcach_ftyp.cxx
b/vcl/generic/glyphs/gcach_ftyp.cxx
index 09a00db..c1d6ddb 100644
--- a/vcl/generic/glyphs/gcach_ftyp.cxx
+++ b/vcl/generic/glyphs/gcach_ftyp.cxx
@@ -1177,7 +1177,7 @@ int ServerFont::ApplyGlyphTransform( int nGlyphFlags,
// ---
-int ServerFont::GetRawGlyphIndex( sal_UCS4 aChar ) const
+int ServerFont::GetRawGlyphIndex(sal_UCS4 aChar, sal_UCS4 aVS) const
{
if( mpFontInfo-IsSymbolFont() )
{
@@ -1216,18 +1216,27 @@ int ServerFont::GetRawGlyphIndex( sal_UCS4 aChar ) const
aChar = aChar*256 + (aTempArray[i] 0xFF);
}
-// cache glyph indexes in font info to share between different sizes
-int nGlyphIndex = mpFontInfo-GetGlyphIndex( aChar );
-if( nGlyphIndex 0 )
+int nGlyphIndex = 0;
+// If asked, check first for variant glyph with the given Unicode variation
+// selector. This is quite uncommon so we don't bother with caching here.
+if (aVS)
+nGlyphIndex = FT_Face_GetCharVariantIndex(maFaceFT, aChar, aVS);
+
+if (nGlyphIndex == 0)
{
-nGlyphIndex = FT_Get_Char_Index( maFaceFT, aChar );
-if( !nGlyphIndex)
+// cache glyph indexes in font info to share between different sizes
+nGlyphIndex = mpFontInfo-GetGlyphIndex( aChar );
+if( nGlyphIndex 0 )
{
-// check if symbol aliasing helps
-if( (aChar = 0x00FF) mpFontInfo-IsSymbolFont() )
-nGlyphIndex = FT_Get_Char_Index( maFaceFT, aChar | 0xF000 );
+nGlyphIndex = FT_Get_Char_Index( maFaceFT, aChar );
+if( !nGlyphIndex)
+{
+// check if symbol aliasing helps
+if( (aChar = 0x00FF) mpFontInfo-IsSymbolFont() )
+nGlyphIndex = FT_Get_Char_Index( maFaceFT, aChar | 0xF000
);
+}
+mpFontInfo-CacheGlyphIndex( aChar, nGlyphIndex );
}
-mpFontInfo-CacheGlyphIndex( aChar, nGlyphIndex );
}
return nGlyphIndex;
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index f7b6907..cb6c195 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -246,13 +246,7 @@ static hb_bool_t getFontGlyph(hb_font_t* /*font*/, void*
pFontData,
void* /*pUserData*/)
{
ServerFont* pFont = (ServerFont*) pFontData;
-*nGlyphIndex = 0;
-
-if (vs)
-*nGlyphIndex = pFont-GetRawGlyphIndex(ch /*, vs*/); // XXX handle
variation selectors
-
-if (*nGlyphIndex == 0)
-*nGlyphIndex = pFont-GetRawGlyphIndex(ch);
+*nGlyphIndex = pFont-GetRawGlyphIndex(ch, vs);
return *nGlyphIndex != 0;
}
diff --git a/vcl/inc/generic/glyphcache.hxx b/vcl/inc/generic/glyphcache.hxx
index cb4ffce..a7e52d9 100644
--- a/vcl/inc/generic/glyphcache.hxx
+++ b/vcl/inc/generic/glyphcache.hxx
@@ -211,7 +211,7 @@ public:
#endif
int GetGlyphIndex( sal_UCS4 ) const;
-int GetRawGlyphIndex( sal_UCS4 ) const;
+int GetRawGlyphIndex( sal_UCS4, sal_UCS4 = 0 ) const;
int FixupGlyphIndex( int nGlyphIndex, sal_UCS4 ) const;
boolGetGlyphOutline( int nGlyphIndex,
::basegfx::B2DPolyPolygon ) const;
boolGetAntialiasAdvice( void ) const;
commit 26ec39fc9f4fecd826983b08b64990ca608e48c4
Author: Khaled Hosny khaledho...@eglug.org
Date: Mon May 6 01:29:33 2013 +0200
Revert #i103131# in doubt treat unicode variation selectors as
invisible(cherry picked from commit 179f88dfe5a1eb2ebd051d73b50f1e0af9c12fd9)
This reverts commit 6840ba613cc46ee65d58612ecabe748d539de9f5.
We don't want this since we can now support variation selectors with
HarfBuzz.
diff --git a/vcl/source/gdi/sallayout.cxx b/vcl/source/gdi/sallayout.cxx
index d4696c7..e90f782 100644
--- a/vcl/source/gdi/sallayout.cxx
+++ b/vcl/source/gdi/sallayout.cxx
@@ -337,11 +337,6 @@ inline bool IsControlChar( sal_UCS4 cChar )
// byte order markers and invalid unicode
if( (cChar == 0xFEFF) || (cChar == 0xFFFE) || (cChar == 0x) )
return true;
-// variation selectors
-if( (0xFE00 = cChar) (cChar = 0xFE0F) )
-return true;
-if( (0xE0100 = cChar) (cChar = 0xE01EF) )
-return true;
return false
[Libreoffice-commits] core.git: 3 commits - config_host/config_harfbuzz.h.in configure.ac vcl/generic vcl/inc vcl/source
config_host/config_harfbuzz.h.in|6 --
configure.ac|9 +
vcl/generic/glyphs/gcach_ftyp.cxx |2 --
vcl/generic/glyphs/gcach_layout.cxx | 29 -
vcl/inc/generic/glyphcache.hxx |8
vcl/inc/sallayout.hxx | 11 +++
vcl/source/gdi/sallayout.cxx|2 +-
7 files changed, 17 insertions(+), 50 deletions(-)
New commits:
commit bff8fa97e16f0f06fddc5545ea36c8bd2b18a580
Author: Khaled Hosny khaledho...@eglug.org
Date: Mon May 6 11:08:29 2013 +0200
Enable HarfBuzz by default
HarfBuzz integration should be functional now, so to give it more wider
testing it is made now a required dependency on non-Windows non-Mac OSs.
By default text layout is now done by HarfBuzz but ICU LayoutEngine is
kept as a fallback and can be enabled with SAL_USE_ICULE env variable.
After 4.1.x is branched, ICU LayoutEngine should be removed completely.
Change-Id: I4fe3beeaf6092f33dd436906c11b83aeafdfbd5d
diff --git a/config_host/config_harfbuzz.h.in b/config_host/config_harfbuzz.h.in
deleted file mode 100644
index b408f52..000
--- a/config_host/config_harfbuzz.h.in
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef CONFIG_HARFBUZZ_H
-#define CONFIG_HARFBUZZ_H
-
-#define ENABLE_HARFBUZZ 0
-
-#endif
diff --git a/configure.ac b/configure.ac
index 75e26bd..cda53d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -720,11 +720,6 @@ AC_ARG_ENABLE(graphite,
[Enables the compilation of Graphite smart font rendering.])
)
-AC_ARG_ENABLE(harfbuzz,
-AS_HELP_STRING([--enable-harfbuzz],
-[Determines whether to use HarfBuzz text layout engine.])
-)
-
AC_ARG_ENABLE(fetch-external,
AS_HELP_STRING([--disable-fetch-external],
[Disables fetching external tarballs from web sources.])
@@ -8482,10 +8477,9 @@ dnl
===
dnl HarfBuzz
dnl ===
AC_MSG_CHECKING([whether to enable HarfBuzz support])
-if test $_os != WINNT -a $_os != Darwin test $enable_harfbuzz =
-o $enable_harfbuzz != no; then
+if test $_os != WINNT -a $_os != Darwin; then
AC_MSG_RESULT([yes])
ENABLE_HARFBUZZ=TRUE
-AC_DEFINE(ENABLE_HARFBUZZ)
libo_CHECK_SYSTEM_MODULE([harfbuzz],[HARFBUZZ],[harfbuzz = 0.9.10])
else
AC_MSG_RESULT([no])
@@ -11978,7 +11972,6 @@ AC_CONFIG_HEADERS([config_host/config_clang.h])
AC_CONFIG_HEADERS([config_host/config_features.h])
AC_CONFIG_HEADERS([config_host/config_global.h])
AC_CONFIG_HEADERS([config_host/config_graphite.h])
-AC_CONFIG_HEADERS([config_host/config_harfbuzz.h])
AC_CONFIG_HEADERS([config_host/config_lgpl.h])
AC_CONFIG_HEADERS([config_host/config_kde4.h])
AC_CONFIG_HEADERS([config_host/config_mingw.h])
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index 935a0e5..7df803f 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -17,7 +17,6 @@
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
-#include config_harfbuzz.h
#include gcach_ftyp.hxx
#include sallayout.hxx
#include salgdi.hxx
@@ -31,10 +30,9 @@
#include sal/alloca.h
#include rtl/instance.hxx
-#if ENABLE_HARFBUZZ
#include harfbuzz/hb-icu.h
#include harfbuzz/hb-ot.h
-#endif
+
#include layout/LayoutEngine.h
#include layout/LEFontInstance.h
#include layout/LELanguages.h
@@ -50,10 +48,7 @@
ServerFontLayout::ServerFontLayout( ServerFont rFont )
: mrServerFont( rFont )
{
-bUseHarfBuzz = false;
-#if ENABLE_HARFBUZZ
-bUseHarfBuzz = (getenv(SAL_USE_HARFBUZZ) != NULL);
-#endif
+bUseHarfBuzz = (getenv(SAL_USE_ICULE) == NULL);
}
void ServerFontLayout::DrawText( SalGraphics rSalGraphics ) const
@@ -208,7 +203,6 @@ static bool needNextCode(sal_Unicode cChar)
return lcl_CharIsJoiner(cChar) || U16_IS_TRAIL(cChar);
}
-#if ENABLE_HARFBUZZ
static hb_blob_t *getFontTable(hb_face_t* /*face*/, hb_tag_t nTableTag, void*
pUserData)
{
char pTagName[5];
@@ -537,7 +531,6 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
return true;
}
-#endif // ENABLE_HARFBUZZ
// ===
// bridge to ICU LayoutEngine
@@ -1214,12 +1207,10 @@ ServerFontLayoutEngine*
ServerFont::GetLayoutEngine(bool bUseHarfBuzz)
{
// find best layout engine for font, platform, script and language
if (!mpLayoutEngine) {
-#if ENABLE_HARFBUZZ
if (bUseHarfBuzz)
mpLayoutEngine = new HbLayoutEngine(*this);
else
-#endif
-mpLayoutEngine = new IcuLayoutEngine(*this);
+mpLayoutEngine = new IcuLayoutEngine(*this);
}
return mpLayoutEngine;
}
commit f0393d7ff69011a16b100541ef18e5090544e4a1
Author: Khaled Hosny khaledho...@eglug.org
Date: Mon May 6 16:54:53 2013 +0200
[harfbuzz] Fix
[Libreoffice-commits] core.git: vcl/source
vcl/source/gdi/outdev3.cxx |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 7556ba312ff3a7409b7da55f220d3ff877505a3b Author: Khaled Hosny khaledho...@eglug.org Date: Mon May 6 21:41:14 2013 +0200 Surely the intent was to check for !pFallback here Change-Id: Ia583cfe1d123903ac8f61ad4a224364af7c77ef7 diff --git a/vcl/source/gdi/outdev3.cxx b/vcl/source/gdi/outdev3.cxx index c1ee2f0..ffd140c 100644 --- a/vcl/source/gdi/outdev3.cxx +++ b/vcl/source/gdi/outdev3.cxx @@ -5967,7 +5967,7 @@ SalLayout* OutputDevice::getFallbackFontThatFits(ImplFontEntry rFallbackFont, pFallback-Release(); pFallback = NULL; } -SAL_WARN_IF(pFallback, vcl.gdi, we couldn't layout text with a smaller point size that worked with a bigger one); +SAL_WARN_IF(!pFallback, vcl.gdi, we couldn't layout text with a smaller point size that worked with a bigger one); } } return pFallback; ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: 2 commits - vcl/coretext
vcl/coretext/salgdi.cxx |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) New commits: commit 543ac5596d0ef3a052973c1ec89a9329d1073dc8 Author: Khaled Hosny khaledho...@eglug.org Date: Thu May 9 23:49:45 2013 +0200 Minor Change-Id: I31b95844234135d14f117ae74124350eedf7d20a diff --git a/vcl/coretext/salgdi.cxx b/vcl/coretext/salgdi.cxx index 227a5c4..58e850d 100644 --- a/vcl/coretext/salgdi.cxx +++ b/vcl/coretext/salgdi.cxx @@ -149,10 +149,10 @@ void QuartzSalGraphics::GetFontMetric( ImplFontMetricData* pMetric, int nFallbac CTFontRef font = m_style-GetFont(); DBG_ASSERT(font, GetFontMetric without font set in style); -pMetric-mnAscent = static_castlong( CTFontGetAscent(font) * mfFakeDPIScale + 0.5); +pMetric-mnAscent = static_castlong(CTFontGetAscent(font) * mfFakeDPIScale + 0.5); pMetric-mnDescent = static_castlong(CTFontGetDescent(font) * mfFakeDPIScale + 0.5); pMetric-mnExtLeading = static_castlong(CTFontGetLeading(font) * mfFakeDPIScale + 0.5); -pMetric-mnIntLeading = 0; +pMetric-mnIntLeading = 0; pMetric-mnWidth = m_style-GetFontStretchedSize(); SAL_INFO( vcl.coretext.gr, commit 924aeb3d039f4ce554b795532e6948fa9065010b Author: Khaled Hosny khaledho...@eglug.org Date: Thu May 9 23:24:17 2013 +0200 [coretext] Fix line spacing It should have been nExtDescent + pMetric-mnDescent, but then the whole thing does not make any sense; why add the descent to the leading and then calculate the leading by subtracting the descent! (well, the ATSUI code was doing this but it makes no sense either). Just use CTFontGetLeading() directly. Change-Id: Ia54648f6c02c11359865f4aa6476adf40b27f906 diff --git a/vcl/coretext/salgdi.cxx b/vcl/coretext/salgdi.cxx index a462c37..227a5c4 100644 --- a/vcl/coretext/salgdi.cxx +++ b/vcl/coretext/salgdi.cxx @@ -151,9 +151,7 @@ void QuartzSalGraphics::GetFontMetric( ImplFontMetricData* pMetric, int nFallbac pMetric-mnAscent = static_castlong( CTFontGetAscent(font) * mfFakeDPIScale + 0.5); pMetric-mnDescent = static_castlong(CTFontGetDescent(font) * mfFakeDPIScale + 0.5); -const long nExtDescent = static_castlong((CTFontGetLeading(font) + CTFontGetDescent(font)) * -mfFakeDPIScale + 0.5); -pMetric-mnExtLeading = nExtDescent + pMetric-mnDescent; +pMetric-mnExtLeading = static_castlong(CTFontGetLeading(font) * mfFakeDPIScale + 0.5); pMetric-mnIntLeading = 0; pMetric-mnWidth = m_style-GetFontStretchedSize(); ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: vcl/coretext
vcl/coretext/salcoretextlayout.cxx | 47 +
1 file changed, 38 insertions(+), 9 deletions(-)
New commits:
commit f2b92a9ab5d1b0c7d3d01db675268b0e1925cdc6
Author: Khaled Hosny khaledho...@eglug.org
Date: Fri May 10 17:05:24 2013 +0200
[coretext] Fix drawing fallback fonts
Core Text will apply its font fallback mechanism when typesetting a
CTLine, and we can't assume that the returned run all use the original
font. This fixes the random glyphs drawn when we hit font fallback.
Change-Id: Id4d7098cb7bd3464cba6abab22be3ac3942c8889
Reviewed-on: https://gerrit.libreoffice.org/3846
Reviewed-by: Tor Lillqvist t...@iki.fi
Tested-by: Tor Lillqvist t...@iki.fi
diff --git a/vcl/coretext/salcoretextlayout.cxx
b/vcl/coretext/salcoretextlayout.cxx
index e324ef7..5599747 100644
--- a/vcl/coretext/salcoretextlayout.cxx
+++ b/vcl/coretext/salcoretextlayout.cxx
@@ -76,6 +76,8 @@ private:
// mutable members since these details are all lazy initialized
mutable int mnGlyphCount;
+mutable CTFontRef* mpGlyphFonts;
+
mutable CGGlyph* mpGlyphs;
mutable CGFloat* mpCharWidths;
mutable int* mpGlyphs2Chars;
@@ -106,6 +108,7 @@ CoreTextLayout::CoreTextLayout(QuartzSalGraphics* graphics,
CoreTextStyleInfo* s
mpStyle(style),
mnCharCount(-1),
mnGlyphCount(-1),
+mpGlyphFonts(NULL),
mpGlyphs(NULL),
mpCharWidths(NULL),
mpGlyphs2Chars(NULL),
@@ -182,6 +185,10 @@ void CoreTextLayout::Justify( long nNewWidth )
void CoreTextLayout::InvalidateMeasurements()
{
+if( mpGlyphFonts ) {
+delete[] mpGlyphFonts;
+mpGlyphFonts = NULL;
+}
if( mpGlyphs ) {
delete[] mpGlyphs;
mpGlyphs = NULL;
@@ -213,14 +220,7 @@ void CoreTextLayout::DrawText( SalGraphics rGraphics )
const
if( mnCharCount = 0 || !gr.CheckContext() )
return;
-CGFontRef cg_font = CTFontCopyGraphicsFont(mpStyle-GetFont(), NULL);
-if( !cg_font ) {
-SAL_INFO( vcl.coretext.layout, Error cg_font is NULL );
-return;
-}
CGContextSaveGState( gr.mrContext );
-CGContextSetFont(gr.mrContext, cg_font);
-CGContextSetFontSize(gr.mrContext, CTFontGetSize(mpStyle-GetFont()));
CGContextSetTextDrawingMode(gr.mrContext, kCGTextFill);
CGContextSetShouldAntialias( gr.mrContext, true );
CGContextSetShouldSubpixelPositionFonts( gr.mrContext, false );
@@ -231,7 +231,7 @@ void CoreTextLayout::DrawText( SalGraphics rGraphics )
const
else {
CGContextSetRGBFillColor(gr.mrContext, 0.0, 0.0, 0.0, 1.0);
}
-CFRelease(cg_font);
+
CGContextSetTextMatrix(gr.mrContext, CGAffineTransformMakeScale(1.0,
-1.0));
CGContextSetShouldAntialias( gr.mrContext, !gr.mbNonAntialiasedText );
@@ -245,7 +245,30 @@ void CoreTextLayout::DrawText( SalGraphics rGraphics )
const
CGContextTranslateCTM(gr.mrContext, pos.X(), pos.Y());
-CGContextShowGlyphsWithAdvances(gr.mrContext, mpGlyphs, mpGlyphAdvances,
mnGlyphCount);
+int i = 0;
+while (i mnGlyphCount)
+{
+CTFontRef pCTFont = mpGlyphFonts[i];
+
+// Find the number of glyphs using the same font
+int nGlyphs = 1;
+while ((i + nGlyphs mnGlyphCount) CFEqual(mpGlyphFonts[i +
nGlyphs], pCTFont))
+nGlyphs++;
+
+CGFontRef pCGFont = CTFontCopyGraphicsFont(pCTFont, NULL);
+if (!pCGFont) {
+SAL_INFO(vcl.coretext.layout, Error pCGFont is NULL);
+return;
+}
+
+CGContextSetFont(gr.mrContext, pCGFont);
+CFRelease(pCGFont);
+CGContextSetFontSize(gr.mrContext, CTFontGetSize(pCTFont));
+
+CGContextShowGlyphsWithAdvances(gr.mrContext, mpGlyphs[i],
mpGlyphAdvances[i], nGlyphs);
+
+i += nGlyphs;
+}
#ifndef IOS
// Request an update of the changed window area. Like in the ATSUI
@@ -572,6 +595,7 @@ void CoreTextLayout::GetMeasurements()
{
InvalidateMeasurements();
+mpGlyphFonts = new CTFontRef[ mnGlyphCount ];
mpGlyphs = new CGGlyph[ mnGlyphCount ];
mpCharWidths = new CGFloat[ mnCharCount ];
mpGlyphs2Chars = new int[ mnGlyphCount ];
@@ -588,6 +612,9 @@ void CoreTextLayout::GetMeasurements()
if ( !run )
continue;
+CFDictionaryRef runAttributes = CTRunGetAttributes(run);
+CTFontRef runFont = (CTFontRef)CFDictionaryGetValue(runAttributes,
kCTFontAttributeName);
+
std::ostringstream glyphPositionInfo;
std::ostringstream glyphAdvancesInfo;
std::ostringstream charWidthInfo;
@@ -622,6 +649,8 @@ void CoreTextLayout::GetMeasurements()
mpGlyphs2Chars[ lineGlyphIx ] = charIx;
mpCharWidths[ charIx ] = mpGlyphAdvances[ lineGlyphIx ].width;
+
+mpGlyphFonts[ lineGlyphIx ] = runFont;
}
#ifdef SAL_LOG_INFO
for ( int i = 0; i runGlyphCount; i
[Libreoffice-commits] core.git: 5 commits - config_host.mk.in configure.ac vcl/generic
config_host.mk.in |1
configure.ac | 27 +---
vcl/generic/glyphs/gcach_ftyp.cxx | 240 +-
3 files changed, 66 insertions(+), 202 deletions(-)
New commits:
commit fe9def183be4025f8c2ebba5f486fff1c20ecc80
Author: Khaled Hosny khaledho...@eglug.org
Date: Sat May 11 08:44:11 2013 +0200
USE_FT_EMBOLDEN has never been used
Change-Id: Idd30f6fcf9d1e4d2af5f49caffa91d6ce30bb196
diff --git a/config_host.mk.in b/config_host.mk.in
index cfe407c..76ac1a7 100644
--- a/config_host.mk.in
+++ b/config_host.mk.in
@@ -540,7 +540,6 @@ export UNIXWRAPPERNAME=@UNIXWRAPPERNAME@
export UNOWINREG_DLL=@UNOWINREG_DLL@
export UPD=@UPD@
export URELIBS=@URELIBS@
-export USE_FT_EMBOLDEN=@USE_FT_EMBOLDEN@
export USE_XINERAMA=@USE_XINERAMA@
export use_shl_version=@use_shl_version@
export UUIDGEN=@UUIDGEN@
diff --git a/configure.ac b/configure.ac
index 5aba388..10d0648 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7308,23 +7308,6 @@ dnl Check for system libwpg
dnl ===
libo_CHECK_SYSTEM_MODULE([libwpg],[WPG],[libwpg-0.2],[-I${OUTDIR}/inc/external],[-L${OUTDIR}/lib
-lwpglib])
-dnl ===
-dnl Check whether freetype2 supports emboldening
-dnl ===
-if test $test_freetype = yes; then
-save_CPPFLAGS=$CPPFLAGS
-save_LDFLAGS=$LDFLAGS
-save_LIBS=$LIBS
-CPPFLAGS=$CPPFLAGS $FREETYPE_CFLAGS
-LDFLAGS=$LDFLAGS $FREETYPE_LIBS
-AC_CHECK_LIB(freetype, FT_GlyphSlot_Embolden,
- [USE_FT_EMBOLDEN=YES], [USE_FT_EMBOLDEN=NO], [])
-LDFLAGS=$save_LDFLAGS
-CPPFLAGS=$save_CPPFLAGS
-LIBS=$save_LIBS
-fi
-AC_SUBST(USE_FT_EMBOLDEN)
-
# ===
# Check for system libxslt
# to prevent incompatibilities between internal libxml2 and external libxslt,
commit 96137f1ef8e1e2c8787b899edf8b2969c2eff5dc
Author: Khaled Hosny khaledho...@eglug.org
Date: Sat May 11 08:29:46 2013 +0200
Drop code for FreeTyope version we don't support
Change-Id: I404ac35010c243fad65b6d83c10c75665a0568f0
diff --git a/vcl/generic/glyphs/gcach_ftyp.cxx
b/vcl/generic/glyphs/gcach_ftyp.cxx
index 1b31f2c..9995964 100644
--- a/vcl/generic/glyphs/gcach_ftyp.cxx
+++ b/vcl/generic/glyphs/gcach_ftyp.cxx
@@ -63,13 +63,8 @@
#endif
#include rtl/instance.hxx
-#ifndef FREETYPE_PATCH
-// VERSION_MINOR in freetype.h is too coarse
-// if patch-level is not available we need to fine-tune the version
ourselves
-#define FTVERSION 2005
-#else
-#define FTVERSION (1000*FREETYPE_MAJOR + 100*FREETYPE_MINOR +
FREETYPE_PATCH)
-#endif
+#define FTVERSION (1000*FREETYPE_MAJOR + 100*FREETYPE_MINOR + FREETYPE_PATCH)
+
#if FTVERSION = 2200
typedef const FT_Vector* FT_Vector_CPtr;
#else // FTVERSION 2200
@@ -521,11 +516,6 @@ FreetypeManager::FreetypeManager()
pFTLibraryVersion( aLibFT, nMajor, nMinor, nPatch );
nFTVERSION = nMajor * 1000 + nMinor * 100 + nPatch;
-// disable embedded bitmaps for Freetype-2.1.3 unless explicitly
-// requested by env var below because it crashes StarOffice on RH9
-// reason: double free in freetype's embedded bitmap handling
-if( nFTVERSION == 2103 )
-nDefaultPrioEmbedded = 0;
// disable artificial emboldening with the Freetype API for older versions
if( nFTVERSION 2110 )
pFTEmbolden = NULL;
@@ -716,14 +706,10 @@ ServerFont::ServerFont( const FontSelectPattern rFSD,
FtFontInfo* pFI )
FT_Encoding eEncoding = FT_ENCODING_UNICODE;
if( mpFontInfo-IsSymbolFont() )
{
-#if (FTVERSION 2000)
-eEncoding = FT_ENCODING_NONE;
-#else
if( FT_IS_SFNT( maFaceFT ) )
eEncoding = ft_encoding_symbol;
else
eEncoding = FT_ENCODING_ADOBE_CUSTOM; // freetype wants this for
PS symbol fonts
-#endif
}
rc = FT_Select_Charmap( maFaceFT, eEncoding );
// no standard encoding applies = we need an encoding converter
@@ -854,13 +840,11 @@ void ServerFont::SetFontOptions(
boost::shared_ptrImplFontOptions pFontOptions
if( mpFontOptions-DontUseHinting() )
mnPrioAutoHint = 0;
-#if (FTVERSION = 2005) || defined(TT_CONFIG_OPTION_BYTECODE_INTERPRETER)
if( mnPrioAutoHint = 0 )
-#endif
mnLoadFlags |= FT_LOAD_NO_HINTING;
#if defined(FT_LOAD_TARGET_LIGHT) defined(FT_LOAD_TARGET_NORMAL)
-if( !(mnLoadFlags FT_LOAD_NO_HINTING) (nFTVERSION = 2103))
+if( !(mnLoadFlags FT_LOAD_NO_HINTING) )
{
mnLoadFlags |= FT_LOAD_TARGET_NORMAL;
switch( mpFontOptions-GetHintStyle() )
@@ -1113,14 +1097,6 @@ int ServerFont::ApplyGlyphTransform( int nGlyphFlags,
// orthogonal transforms are better handled by bitmap operations
if( bStretched || (bForBitmapProcessing (nAngle % 900) != 0
[Libreoffice-commits] core.git: vcl/coretext
vcl/coretext/salcoretextlayout.cxx | 62 +
1 file changed, 30 insertions(+), 32 deletions(-)
New commits:
commit c049df6fdd14fdfd88ded76ac9396efa8877f2c5
Author: Khaled Hosny khaledho...@eglug.org
Date: Sat May 11 21:04:45 2013 +0200
[coretext] Attempt to fix jumping lines
No more jumping and spaces between text runs are not eaten, but text
selection is still broken, as well as editing.
Change-Id: Ic9d2a6df0add20b63d6edf0ddf84b7d6f8de0983
diff --git a/vcl/coretext/salcoretextlayout.cxx
b/vcl/coretext/salcoretextlayout.cxx
index 5599747..109900f 100644
--- a/vcl/coretext/salcoretextlayout.cxx
+++ b/vcl/coretext/salcoretextlayout.cxx
@@ -308,34 +308,37 @@ void CoreTextLayout::DropGlyph( int /*nStart*/ )
long CoreTextLayout::FillDXArray( sal_Int32* pDXArray ) const
{
-// Short circuit requests which don't need full details
-if( !pDXArray ) {
-return GetTextWidth();
-}
+if (pDXArray)
+{
+for (int i = 0; i mnCharCount; i++)
+pDXArray[i] = 0;
-// Distribute the widths among the string elements
-long width = 0;
-float scale = mpStyle-GetFontStretchFactor();
-CGFloat accumulatedWidth = 0;
-
-std::ostringstream DXArrayInfo;
-for( int i = 0; i mnCharCount; ++i ) {
-// Convert and adjust for accumulated rounding errors
-accumulatedWidth += mpCharWidths[ i ];
-const long old_width = width;
-width = round_to_long( accumulatedWidth * scale );
-pDXArray[i] = width - old_width;
-#ifdef SAL_LOG_INFO
-if ( i 7 )
-DXArrayInfo pDXArray[i];
-else if ( i == 7 )
-DXArrayInfo ...;
-#endif
-}
+CFArrayRef runs = CTLineGetGlyphRuns(mpLine);
+const CFIndex nRuns = CFArrayGetCount(runs);
+
+for (CFIndex runIndex = 0; runIndex nRuns; runIndex++)
+{
+CTRunRef run = (CTRunRef)CFArrayGetValueAtIndex(runs, runIndex);
+if (!run)
+continue;
-SAL_INFO( vcl.coretext.layout, FillDXArray( this ):
DXArrayInfo.str() , result= width );
+const CFIndex runGlyphCount = CTRunGetGlyphCount(run);
+if (runGlyphCount)
+{
+CFIndex runStringIndices[runGlyphCount];
+CGSize runGlyphAdvances[runGlyphCount];
+CTRunGetStringIndices(run, CFRangeMake(0, 0),
runStringIndices);
+CTRunGetAdvances(run, CFRangeMake(0, 0), runGlyphAdvances);
+for (int i = 0; i runGlyphCount; i++)
+{
+const CFIndex charIndex = runStringIndices[i];
+pDXArray[charIndex] += runGlyphAdvances[i].width;
+}
+}
+}
+}
-return width;
+return GetTextWidth();
}
bool CoreTextLayout::GetBoundRect( SalGraphics rGraphics, Rectangle rVCLRect
) const
@@ -508,13 +511,8 @@ int CoreTextLayout::GetTextBreak( long nMaxWidth, long
nCharExtra, int nFactor )
long CoreTextLayout::GetTextWidth() const
{
-CGContextRef context = mpGraphics-GetContext();
-if (!context) {
-SAL_INFO( vcl.coretext.layout, GetTextWidth(): no context!?);
-return 0;
-}
-CGRect bound_rect = CTLineGetImageBounds(mpLine, context);
-long w = round_to_long((bound_rect.size.width +
CTLineGetTrailingWhitespaceWidth(mpLine)) * mpStyle-GetFontStretchFactor());
+double width = CTLineGetTypographicBounds(mpLine, NULL, NULL, NULL);
+long w = round_to_long(width + CTLineGetTrailingWhitespaceWidth(mpLine));
SAL_INFO( vcl.coretext.layout, GetTextWidth( this ) returning
w );
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: vcl/generic
vcl/generic/glyphs/gcach_layout.cxx | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
New commits:
commit 2ede6c95e6481c92cc199e7d74fd36c841636304
Author: Khaled Hosny khaledho...@eglug.org
Date: Sun May 12 17:59:50 2013 +0200
Some logging
Change-Id: I4515d4d6760e22ce4d77fbb3cbce93e3ce097b98
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index 55ddaee..07f9f76 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -203,6 +203,21 @@ static bool needNextCode(sal_Unicode cChar)
return lcl_CharIsJoiner(cChar) || U16_IS_TRAIL(cChar);
}
+std::ostream operator (std::ostream s, ServerFont* pFont)
+{
+#ifndef SAL_LOG_INFO
+(void) pFont;
+#else
+FT_Face aFace = pFont-GetFtFace();
+const char* pName = FT_Get_Postscript_Name(aFace);
+if (pName)
+s pName;
+else
+s pFont-GetFontFileName();
+#endif
+return s;
+}
+
static hb_blob_t *getFontTable(hb_face_t* /*face*/, hb_tag_t nTableTag, void*
pUserData)
{
char pTagName[5];
@@ -213,6 +228,9 @@ static hb_blob_t *getFontTable(hb_face_t* /*face*/,
hb_tag_t nTableTag, void* pU
pTagName[4] = 0;
ServerFont* pFont = (ServerFont*) pUserData;
+
+SAL_INFO(vcl.harfbuzz.layout, getFontTable( pFont ,
pTagName ));
+
sal_uLong nLength;
const unsigned char* pBuffer = pFont-GetTable(pTagName, nLength);
@@ -284,6 +302,8 @@ static hb_position_t getGlyphKerningH(hb_font_t* /*font*/,
void* pFontData,
ServerFont* pFont = (ServerFont*) pFontData;
FT_Face aFace = pFont-GetFtFace();
+SAL_INFO(vcl.harfbuzz.layout, getGlyphKerningH( pFont ,
nGlyphIndex1 , nGlyphIndex2 ));
+
FT_Error error;
FT_Vector kerning;
hb_position_t ret;
@@ -312,8 +332,10 @@ static hb_bool_t getGlyphExtents(hb_font_t* /*font*/,
void* pFontData,
{
ServerFont* pFont = (ServerFont*) pFontData;
FT_Face aFace = pFont-GetFtFace();
-FT_Error error;
+SAL_INFO(vcl.harfbuzz.layout, getGlyphExtents( pFont ,
nGlyphIndex ));
+
+FT_Error error;
error = FT_Load_Glyph(aFace, nGlyphIndex, FT_LOAD_DEFAULT);
if (!error)
{
@@ -331,11 +353,13 @@ static hb_bool_t getGlyphContourPoint(hb_font_t*
/*font*/, void* pFontData,
hb_position_t *x, hb_position_t *y,
void* /*pUserData*/)
{
+bool ret = false;
ServerFont* pFont = (ServerFont*) pFontData;
FT_Face aFace = pFont-GetFtFace();
-FT_Error error;
-bool ret = false;
+SAL_INFO(vcl.harfbuzz.layout, getGlyphContourPoint( pFont ,
nGlyphIndex , nPointIndex ));
+
+FT_Error error;
error = FT_Load_Glyph(aFace, nGlyphIndex, FT_LOAD_DEFAULT);
if (!error)
{
@@ -407,6 +431,8 @@ bool HbLayoutEngine::layout(ServerFontLayout rLayout,
ImplLayoutArgs rArgs)
ServerFont rFont = rLayout.GetServerFont();
FT_Face aFtFace = rFont.GetFtFace();
+SAL_INFO(vcl.harfbuzz.layout, layout( this ,rArgs= rArgs
));
+
hb_font_t *pHbFont = hb_font_create(mpHbFace);
hb_font_set_funcs(pHbFont, getFontFuncs(), rFont, NULL);
hb_font_set_scale(pHbFont,
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: vcl/generic
vcl/generic/glyphs/gcach_ftyp.cxx |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit c0417e82174297ace604c68fc577c831929f3573
Author: Khaled Hosny khaledho...@eglug.org
Date: Mon May 13 02:33:14 2013 +0200
Typo
Change-Id: I28ea63722f542a79aef904f9be40645baac191e4
diff --git a/vcl/generic/glyphs/gcach_ftyp.cxx
b/vcl/generic/glyphs/gcach_ftyp.cxx
index 9995964..bd1ef26 100644
--- a/vcl/generic/glyphs/gcach_ftyp.cxx
+++ b/vcl/generic/glyphs/gcach_ftyp.cxx
@@ -978,7 +978,7 @@ void ServerFont::FetchFontMetric( ImplFontMetricData rTo,
long rFactor ) const
{
rTo.mnAscent = pOS2-usWinAscent * fScale + 0.5;
rTo.mnDescent = pOS2-usWinDescent * fScale + 0.5;
-rTo.mnDescent = 0;
+rTo.mnExtLeading = 0;
}
}
}
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: vcl/generic
vcl/generic/glyphs/gcach_ftyp.cxx | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
New commits:
commit dd5b15ebd868e21b4c948ccb7978136a91a7992c
Author: Khaled Hosny khaledho...@eglug.org
Date: Mon May 13 16:32:20 2013 +0200
Handle fonts without hhea or OS/2 table e.g. Type1
Change-Id: Ib7245e9f8b7874087966cb1098e63d1f83acaa6a
diff --git a/vcl/generic/glyphs/gcach_ftyp.cxx
b/vcl/generic/glyphs/gcach_ftyp.cxx
index bd1ef26..162ba11 100644
--- a/vcl/generic/glyphs/gcach_ftyp.cxx
+++ b/vcl/generic/glyphs/gcach_ftyp.cxx
@@ -945,8 +945,10 @@ void ServerFont::FetchFontMetric( ImplFontMetricData rTo,
long rFactor ) const
// Calculating ascender and descender:
// FreeType = 2.4.6 does the right thing, so we just use what it gives us,
-// for earlier versions we emulate its behaviour; take them from 'hhea'
-// table, if zero take them from 'OS/2' table.
+// for earlier versions we emulate its behaviour;
+// take them from 'hhea' table,
+// if zero take them from 'OS/2' table,
+// if zero take them from FreeType's font metrics
if (nFTVERSION = 2406)
{
const FT_Size_Metrics rMetrics = maFaceFT-size-metrics;
@@ -982,6 +984,14 @@ void ServerFont::FetchFontMetric( ImplFontMetricData rTo,
long rFactor ) const
}
}
}
+
+if (!(rTo.mnAscent || rTo.mnDescent))
+{
+const FT_Size_Metrics rMetrics = maFaceFT-size-metrics;
+rTo.mnAscent = (rMetrics.ascender + 32) 6;
+rTo.mnDescent = (-rMetrics.descender + 32) 6;
+rTo.mnExtLeading = ((rMetrics.height + 32) 6) - (rTo.mnAscent +
rTo.mnDescent);
+}
}
if( pOS2 (pOS2-version != 0x) )
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: 4 commits - vcl/coretext
vcl/coretext/salcoretextlayout.cxx | 107 +++--
1 file changed, 46 insertions(+), 61 deletions(-)
New commits:
commit e4088a68aa3d69da60f5a1e93c06ca8be3ff764f
Author: Khaled Hosny khaledho...@eglug.org
Date: Fri May 17 23:23:02 2013 +0200
Drop unused mpGlyphPositions array
Change-Id: I858832a41ef140fa9916e05548edf2df6b0af451
diff --git a/vcl/coretext/salcoretextlayout.cxx
b/vcl/coretext/salcoretextlayout.cxx
index 650506d..d2c2d48 100644
--- a/vcl/coretext/salcoretextlayout.cxx
+++ b/vcl/coretext/salcoretextlayout.cxx
@@ -81,7 +81,6 @@ private:
mutable CGSize* mpGlyphAdvances;
-mutable CGPoint* mpGlyphPositions;
mutable CTTypesetterRef mpTypesetter;
mutable CTLineRef mpLine;
mutable bool mbHasBoundRectangle;
@@ -108,7 +107,6 @@ CoreTextLayout::CoreTextLayout(CoreTextStyleInfo* style) :
mpCharWidths(NULL),
mpGlyphs2Chars(NULL),
mpGlyphAdvances(NULL),
-mpGlyphPositions(NULL),
mpTypesetter(NULL),
mpLine(NULL),
mbHasBoundRectangle(false),
@@ -196,10 +194,6 @@ void CoreTextLayout::InvalidateMeasurements()
delete[] mpGlyphAdvances;
mpGlyphAdvances = NULL;
}
-if( mpGlyphPositions ) {
-delete[] mpGlyphPositions;
-mpGlyphPositions = NULL;
-}
mbHasBoundRectangle = false;
}
@@ -601,7 +595,6 @@ void CoreTextLayout::GetMeasurements()
mpCharWidths = new CGFloat[ mnCharCount ];
mpGlyphs2Chars = new int[ mnGlyphCount ];
mpGlyphAdvances = new CGSize[ mnGlyphCount ];
-mpGlyphPositions = new CGPoint[ mnGlyphCount ];
CFArrayRef runs = CTLineGetGlyphRuns( mpLine );
const CFIndex nRuns = CFArrayGetCount( runs );
@@ -630,7 +623,6 @@ void CoreTextLayout::GetMeasurements()
CTRunGetGlyphs( run, CFRangeMake( 0, 0 ), mpGlyphs[ lineGlyphIx ]
);
-CTRunGetPositions( run, CFRangeMake( 0, 0 ), mpGlyphPositions[
lineGlyphIx ] );
CTRunGetAdvances( run, CFRangeMake( 0, 0 ), mpGlyphAdvances[
lineGlyphIx ] );
for ( CFIndex runGlyphIx = 0 ; runGlyphIx runGlyphCount;
lineGlyphIx++, runGlyphIx++ )
@@ -645,7 +637,7 @@ void CoreTextLayout::GetMeasurements()
for ( int i = 0; i runGlyphCount; i++ ) {
const int ix = lineRunGlyphStartIx + i;
if ( i 7 ) {
-glyphPositionInfo mpGlyphs[ ix ] @
mpGlyphPositions[ ix ];
+glyphPositionInfo mpGlyphs[ ix ];
glyphAdvancesInfo mpGlyphAdvances[ ix ];
} else if (i == 7 ) {
glyphPositionInfo ...;
commit 81ec93f8448d32933e2697613449baf573b63e42
Author: Khaled Hosny khaledho...@eglug.org
Date: Fri May 17 23:17:54 2013 +0200
Simplify Core Text drawing
No need to keep a fonts array around; we donât modify the glyph array in
anyway so we can just query the CTLine directly.
Change-Id: I24fd49b8fcc8391de7fe132db60bc81bc9941a81
diff --git a/vcl/coretext/salcoretextlayout.cxx
b/vcl/coretext/salcoretextlayout.cxx
index e4afc8d..650506d 100644
--- a/vcl/coretext/salcoretextlayout.cxx
+++ b/vcl/coretext/salcoretextlayout.cxx
@@ -75,8 +75,6 @@ private:
// mutable members since these details are all lazy initialized
mutable int mnGlyphCount;
-mutable CTFontRef* mpGlyphFonts;
-
mutable CGGlyph* mpGlyphs;
mutable CGFloat* mpCharWidths;
mutable int* mpGlyphs2Chars;
@@ -106,7 +104,6 @@ CoreTextLayout::CoreTextLayout(CoreTextStyleInfo* style) :
mpStyle(style),
mnCharCount(-1),
mnGlyphCount(-1),
-mpGlyphFonts(NULL),
mpGlyphs(NULL),
mpCharWidths(NULL),
mpGlyphs2Chars(NULL),
@@ -183,10 +180,6 @@ void CoreTextLayout::Justify( long nNewWidth )
void CoreTextLayout::InvalidateMeasurements()
{
-if( mpGlyphFonts ) {
-delete[] mpGlyphFonts;
-mpGlyphFonts = NULL;
-}
if( mpGlyphs ) {
delete[] mpGlyphs;
mpGlyphs = NULL;
@@ -243,29 +236,37 @@ void CoreTextLayout::DrawText( SalGraphics rGraphics )
const
CGContextTranslateCTM(gr.mrContext, pos.X(), pos.Y());
-int i = 0;
-while (i mnGlyphCount)
-{
-CTFontRef pCTFont = mpGlyphFonts[i];
+CFArrayRef pRuns = CTLineGetGlyphRuns(mpLine);
+const CFIndex nRuns = CFArrayGetCount(pRuns);
-// Find the number of glyphs using the same font
-int nGlyphs = 1;
-while ((i + nGlyphs mnGlyphCount) CFEqual(mpGlyphFonts[i +
nGlyphs], pCTFont))
-nGlyphs++;
-
-CGFontRef pCGFont = CTFontCopyGraphicsFont(pCTFont, NULL);
-if (!pCGFont) {
-SAL_INFO(vcl.coretext.layout, Error pCGFont is NULL);
-return;
-}
+for (CFIndex nRun = 0; nRun nRuns; nRun++)
+{
+CTRunRef pRun = (CTRunRef)CFArrayGetValueAtIndex(pRuns, nRun);
+if (!pRun)
+continue;
-CGContextSetFont(gr.mrContext, pCGFont
[Libreoffice-commits] core.git: sw/source
sw/source/ui/docvw/HeaderFooterWin.cxx |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit c761fcfd7ec95090cde2fb2b6b9b891f3e1337ab Author: Khaled Hosny khaledho...@eglug.org Date: Mon May 20 15:58:47 2013 +0200 Fix fdo#64751 â Header footer blue tags empty No idea FontMetric::GetHeight() is supposed to mean, probably the code here meant GetLineHeight(). What it actually need is GetAscent(), so use it instead (which is the same as GetLineHeight() - GetDescent()). Change-Id: Ic467e56ed6b8d245ac7800f94e6d40030833328b Reviewed-on: https://gerrit.libreoffice.org/3980 Reviewed-by: Fridrich Strba fridr...@documentfoundation.org Tested-by: Fridrich Strba fridr...@documentfoundation.org diff --git a/sw/source/ui/docvw/HeaderFooterWin.cxx b/sw/source/ui/docvw/HeaderFooterWin.cxx index 970e541..eb88d53 100644 --- a/sw/source/ui/docvw/HeaderFooterWin.cxx +++ b/sw/source/ui/docvw/HeaderFooterWin.cxx @@ -291,7 +291,7 @@ void SwHeaderFooterWin::Paint( const Rectangle ) GetTextBoundRect( aTextRect, String( m_sLabel ) ); FontMetric aFontMetric = GetFontMetric( GetFont() ); -double nTextOffsetY = aFontMetric.GetHeight() - aFontMetric.GetDescent() + TEXT_PADDING; +double nTextOffsetY = aFontMetric.GetAscent() + TEXT_PADDING; Point aTextPos( TEXT_PADDING, nTextOffsetY ); basegfx::B2DHomMatrix aTextMatrix( createScaleTranslateB2DHomMatrix( ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: download.lst harfbuzz/harfbuzz.configure.patch.1
download.lst|2 +-
harfbuzz/harfbuzz.configure.patch.1 |8 +---
2 files changed, 2 insertions(+), 8 deletions(-)
New commits:
commit b1167d96bd70a9e820525a3e6189772cf1b7852a
Author: Khaled Hosny khaledho...@eglug.org
Date: Tue May 21 19:46:06 2013 +0200
Update HarfBuzz to 0.9.17
Change-Id: If84a1eb7dbd54b4f1e3d876eb63cc3f2f8e51938
Reviewed-on: https://gerrit.libreoffice.org/3993
Reviewed-by: Fridrich Strba fridr...@documentfoundation.org
Tested-by: Fridrich Strba fridr...@documentfoundation.org
diff --git a/download.lst b/download.lst
index f02392e..f827956 100644
--- a/download.lst
+++ b/download.lst
@@ -38,7 +38,7 @@ export GRAPHITE_TARBALL :=
f5ef3f7f10fa8c3542c6a085a233080b-graphite2-1.2.0.tgz
export GLIBC_TARBALL :=
4a660ce8466c9df01f19036435425c3a-glibc-2.1.3-stub.tar.gz
export HSQLDB_TARBALL := 17410483b5b5f267aa18b7e00b65e6e0-hsqldb_1_8_0.zip
export HUNSPELL_TARBALL :=
3121aaf3e13e5d88dfff13fb4a5f1ab8-hunspell-1.3.2.tar.gz
-export HARFBUZZ_TARBALL :=
90855e670c790c1fec4592908be3c0b8-harfbuzz-0.9.16.tar.bz2
+export HARFBUZZ_TARBALL :=
c48827713e93539dc7285f9e86ffbdc5-harfbuzz-0.9.17.tar.bz2
export HYPHEN_TARBALL := a2f6010987e1c601274ab5d63b72c944-hyphen-2.8.4.tar.gz
export ICU_TARBALL := 6eef33b229d0239d654983028c9c7053-icu4c-51_1-src.tgz
export ICU_51_LAYOUT_FIX_TARBALL :=
7650341b04f05ff2595bf064f3e41f41-icu-51-layout-fix-10107.tgz
diff --git a/harfbuzz/harfbuzz.configure.patch.1
b/harfbuzz/harfbuzz.configure.patch.1
index ffabde5..937a06e 100644
--- a/harfbuzz/harfbuzz.configure.patch.1
+++ b/harfbuzz/harfbuzz.configure.patch.1
@@ -64,7 +64,7 @@ diff -ur harfbuzz.org/configure harfbuzz/configure
fi
if test $have_icu_le != true; then
if test -n $ac_tool_prefix; then
-@@ -17555,12 +17555,12 @@
+@@ -17555,7 +17555,7 @@
{ $as_echo $as_me:${as_lineno-$LINENO}: checking for ICU_LE by using
icu-config fallback 5
$as_echo_n checking for ICU_LE by using icu-config fallback... 6; }
if test $ICU_CONFIG != no $ICU_CONFIG --version /dev/null;
then
@@ -73,12 +73,6 @@ diff -ur harfbuzz.org/configure harfbuzz/configure
# We don't use --cflags as this gives us a lot of things that
we don't
# necessarily want, like debugging and optimization flags
# See man (1) icu-config for more info.
- ICU_LE_CFLAGS=`$ICU_CONFIG --cppflags`
-- ICU_LE_LIBS=`$ICU_CONFIG --ldflags-libsonly --ldflags-layout`
-+ ICU_LE_LIBS=`$ICU_CONFIG --ldflags-libsonly --ldflags-layout |
tr \n `
-
-
- { $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
@@ -17654,7 +17654,7 @@
GRAPHITE2_LIBS=$pkg_cv_GRAPHITE2_LIBS
{ $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: harfbuzz/harfbuzz.configure.patch.1
harfbuzz/harfbuzz.configure.patch.1 |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
New commits:
commit a2e3f7786f78234a5b5d0fe19ea715c2ad2f3ad7
Author: Khaled Hosny khaledho...@eglug.org
Date: Wed May 22 12:04:22 2013 +0200
Blind attempt to fix HarfBuzz build
Change-Id: Iaa61bc2c82ab6bd6391c8c81951ca55c5ce133ab
diff --git a/harfbuzz/harfbuzz.configure.patch.1
b/harfbuzz/harfbuzz.configure.patch.1
index 937a06e..c66e2b7 100644
--- a/harfbuzz/harfbuzz.configure.patch.1
+++ b/harfbuzz/harfbuzz.configure.patch.1
@@ -64,7 +64,7 @@ diff -ur harfbuzz.org/configure harfbuzz/configure
fi
if test $have_icu_le != true; then
if test -n $ac_tool_prefix; then
-@@ -17555,7 +17555,7 @@
+@@ -17555,12 +17555,12 @@
{ $as_echo $as_me:${as_lineno-$LINENO}: checking for ICU_LE by using
icu-config fallback 5
$as_echo_n checking for ICU_LE by using icu-config fallback... 6; }
if test $ICU_CONFIG != no $ICU_CONFIG --version /dev/null;
then
@@ -73,6 +73,12 @@ diff -ur harfbuzz.org/configure harfbuzz/configure
# We don't use --cflags as this gives us a lot of things that
we don't
# necessarily want, like debugging and optimization flags
# See man (1) icu-config for more info.
+ ICU_LE_CFLAGS=`$ICU_CONFIG --cppflags`
+- ICU_LE_LIBS=`$ICU_CONFIG --ldflags-searchpath
--ldflags-libsonly --ldflags-layout`
++ ICU_LE_LIBS=`$ICU_CONFIG --ldflags-searchpath
--ldflags-libsonly --ldflags-layout | tr \n `
+
+
+ { $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
@@ -17654,7 +17654,7 @@
GRAPHITE2_LIBS=$pkg_cv_GRAPHITE2_LIBS
{ $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'libreoffice-4-1' - 2 commits - download.lst harfbuzz/harfbuzz.configure.patch.1
download.lst|2 +-
harfbuzz/harfbuzz.configure.patch.1 |8
2 files changed, 5 insertions(+), 5 deletions(-)
New commits:
commit 0ba159e33bb8f47250f57f377af40f7ca941c89c
Author: Khaled Hosny khaledho...@eglug.org
Date: Wed May 22 12:04:22 2013 +0200
Blind attempt to fix HarfBuzz build
Change-Id: Iaa61bc2c82ab6bd6391c8c81951ca55c5ce133ab
diff --git a/harfbuzz/harfbuzz.configure.patch.1
b/harfbuzz/harfbuzz.configure.patch.1
index 937a06e..c66e2b7 100644
--- a/harfbuzz/harfbuzz.configure.patch.1
+++ b/harfbuzz/harfbuzz.configure.patch.1
@@ -64,7 +64,7 @@ diff -ur harfbuzz.org/configure harfbuzz/configure
fi
if test $have_icu_le != true; then
if test -n $ac_tool_prefix; then
-@@ -17555,7 +17555,7 @@
+@@ -17555,12 +17555,12 @@
{ $as_echo $as_me:${as_lineno-$LINENO}: checking for ICU_LE by using
icu-config fallback 5
$as_echo_n checking for ICU_LE by using icu-config fallback... 6; }
if test $ICU_CONFIG != no $ICU_CONFIG --version /dev/null;
then
@@ -73,6 +73,12 @@ diff -ur harfbuzz.org/configure harfbuzz/configure
# We don't use --cflags as this gives us a lot of things that
we don't
# necessarily want, like debugging and optimization flags
# See man (1) icu-config for more info.
+ ICU_LE_CFLAGS=`$ICU_CONFIG --cppflags`
+- ICU_LE_LIBS=`$ICU_CONFIG --ldflags-searchpath
--ldflags-libsonly --ldflags-layout`
++ ICU_LE_LIBS=`$ICU_CONFIG --ldflags-searchpath
--ldflags-libsonly --ldflags-layout | tr \n `
+
+
+ { $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
@@ -17654,7 +17654,7 @@
GRAPHITE2_LIBS=$pkg_cv_GRAPHITE2_LIBS
{ $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
commit 1cabbe033b395d5de985dd77ecd26dfc39a6feeb
Author: Khaled Hosny khaledho...@eglug.org
Date: Tue May 21 19:46:06 2013 +0200
Update HarfBuzz to 0.9.17
Change-Id: If84a1eb7dbd54b4f1e3d876eb63cc3f2f8e51938
Reviewed-on: https://gerrit.libreoffice.org/3993
Reviewed-by: Fridrich Strba fridr...@documentfoundation.org
Tested-by: Fridrich Strba fridr...@documentfoundation.org
diff --git a/download.lst b/download.lst
index f02392e..f827956 100644
--- a/download.lst
+++ b/download.lst
@@ -38,7 +38,7 @@ export GRAPHITE_TARBALL :=
f5ef3f7f10fa8c3542c6a085a233080b-graphite2-1.2.0.tgz
export GLIBC_TARBALL :=
4a660ce8466c9df01f19036435425c3a-glibc-2.1.3-stub.tar.gz
export HSQLDB_TARBALL := 17410483b5b5f267aa18b7e00b65e6e0-hsqldb_1_8_0.zip
export HUNSPELL_TARBALL :=
3121aaf3e13e5d88dfff13fb4a5f1ab8-hunspell-1.3.2.tar.gz
-export HARFBUZZ_TARBALL :=
90855e670c790c1fec4592908be3c0b8-harfbuzz-0.9.16.tar.bz2
+export HARFBUZZ_TARBALL :=
c48827713e93539dc7285f9e86ffbdc5-harfbuzz-0.9.17.tar.bz2
export HYPHEN_TARBALL := a2f6010987e1c601274ab5d63b72c944-hyphen-2.8.4.tar.gz
export ICU_TARBALL := 6eef33b229d0239d654983028c9c7053-icu4c-51_1-src.tgz
export ICU_51_LAYOUT_FIX_TARBALL :=
7650341b04f05ff2595bf064f3e41f41-icu-51-layout-fix-10107.tgz
diff --git a/harfbuzz/harfbuzz.configure.patch.1
b/harfbuzz/harfbuzz.configure.patch.1
index ffabde5..937a06e 100644
--- a/harfbuzz/harfbuzz.configure.patch.1
+++ b/harfbuzz/harfbuzz.configure.patch.1
@@ -64,7 +64,7 @@ diff -ur harfbuzz.org/configure harfbuzz/configure
fi
if test $have_icu_le != true; then
if test -n $ac_tool_prefix; then
-@@ -17555,12 +17555,12 @@
+@@ -17555,7 +17555,7 @@
{ $as_echo $as_me:${as_lineno-$LINENO}: checking for ICU_LE by using
icu-config fallback 5
$as_echo_n checking for ICU_LE by using icu-config fallback... 6; }
if test $ICU_CONFIG != no $ICU_CONFIG --version /dev/null;
then
@@ -73,12 +73,6 @@ diff -ur harfbuzz.org/configure harfbuzz/configure
# We don't use --cflags as this gives us a lot of things that
we don't
# necessarily want, like debugging and optimization flags
# See man (1) icu-config for more info.
- ICU_LE_CFLAGS=`$ICU_CONFIG --cppflags`
-- ICU_LE_LIBS=`$ICU_CONFIG --ldflags-libsonly --ldflags-layout`
-+ ICU_LE_LIBS=`$ICU_CONFIG --ldflags-libsonly --ldflags-layout |
tr \n `
-
-
- { $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
@@ -17654,7 +17654,7 @@
GRAPHITE2_LIBS=$pkg_cv_GRAPHITE2_LIBS
{ $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: vcl/generic vcl/inc vcl/source
vcl/generic/glyphs/gcach_layout.cxx | 96
vcl/inc/generic/glyphcache.hxx |1
vcl/source/gdi/sallayout.cxx|4 -
3 files changed, 2 insertions(+), 99 deletions(-)
New commits:
commit 736adbb4687eaa6b6a7a350a6452df2eceaad960
Author: Khaled Hosny khaledho...@eglug.org
Date: Thu May 23 09:34:27 2013 +0200
Fix left to right full justification
I was overloading ApplyDXArray() with a HarfBuzz specific implementation
because the GenericSalLayout one was screwing right to left kerning, but
it seems to have broken left to right full justifications. Since
mnXOffset was introduced a bit earlier to fix a similar issue, it can
now be used here as well to minimize the possible side effects.
Seems to work fine for both left to right and right to left text now,
but at least one of my Arabic tests is regressing, so might need some
tweaking.
Change-Id: I1239b0ec77a4978f981a480400a6d01cda18af79
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index 07f9f76..6ac7fd4 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -90,102 +90,6 @@ void ServerFontLayout::AdjustLayout( ImplLayoutArgs rArgs )
}
}
-// apply adjustments to glyph advances, e.g. as a result of justification.
-void ServerFontLayout::ApplyDXArray(ImplLayoutArgs rArgs)
-{
-if (bUseHarfBuzz)
-{
-if (m_GlyphItems.empty())
-return;
-
-// determine cluster boundaries and x base offset
-const int nCharCount = rArgs.mnEndCharPos - rArgs.mnMinCharPos;
-int* pLogCluster = (int*)alloca(nCharCount * sizeof(int));
-size_t i;
-int n,p;
-long nBasePointX = -1;
-if (mnLayoutFlags SAL_LAYOUT_FOR_FALLBACK)
-nBasePointX = 0;
-for (p = 0; p nCharCount; ++p)
-pLogCluster[p] = -1;
-
-for (i = 0; i m_GlyphItems.size(); ++i)
-{
-n = m_GlyphItems[i].mnCharPos - rArgs.mnMinCharPos;
-if ((n 0) || (nCharCount = n))
-continue;
-if (pLogCluster[n] 0)
-pLogCluster[n] = i;
-if (nBasePointX 0)
-nBasePointX = m_GlyphItems[i].maLinearPos.X();
-}
-// retarget unresolved pLogCluster[n] to a glyph inside the cluster
-// TODO: better do it while the deleted-glyph markers are still there
-for (n = 0; n nCharCount; ++n)
-if ((p = pLogCluster[0]) = 0)
-break;
-if (n = nCharCount)
-return;
-for (n = 0; n nCharCount; ++n)
-{
-if (pLogCluster[n] 0)
-pLogCluster[n] = p;
-else
-p = pLogCluster[n];
-}
-
-// calculate adjusted cluster widths
-sal_Int32* pNewGlyphWidths = (sal_Int32*)alloca(m_GlyphItems.size() *
sizeof(sal_Int32));
-for (i = 0; i m_GlyphItems.size(); ++i)
-pNewGlyphWidths[i] = 0;
-
-bool bRTL;
-for (int nCharPos = p = -1; rArgs.GetNextPos(nCharPos, bRTL); )
-{
-n = nCharPos - rArgs.mnMinCharPos;
-if ((n 0) || (nCharCount = n)) continue;
-
-if (pLogCluster[n] = 0)
-p = pLogCluster[n];
-if (p = 0)
-{
-long nDelta = rArgs.mpDXArray[n];
-if(n 0)
-nDelta -= rArgs.mpDXArray[n - 1];
-pNewGlyphWidths[p] += nDelta * mnUnitsPerPixel;
-}
-}
-
-// move cluster positions using the adjusted widths
-long nDelta = 0;
-for (i = 0; i m_GlyphItems.size(); ++i)
-{
-if (m_GlyphItems[i].IsClusterStart())
-{
-// calculate original and adjusted cluster width
-int nOldClusterWidth = m_GlyphItems[i].mnNewWidth;
-int nNewClusterWidth = pNewGlyphWidths[i];
-size_t j;
-for (j = i; ++j m_GlyphItems.size(); )
-{
-if (m_GlyphItems[j].IsClusterStart())
-break;
-if (!m_GlyphItems[j].IsDiacritic()) // #i99367# ignore
diacritics
-nOldClusterWidth += m_GlyphItems[j].mnNewWidth;
-nNewClusterWidth += pNewGlyphWidths[j];
-}
-nDelta += nNewClusterWidth - nOldClusterWidth;
-}
-m_GlyphItems[i].mnNewWidth = pNewGlyphWidths[i];
-m_GlyphItems[i].maLinearPos.X() += nDelta;
-}
-}
-else
-{
-GenericSalLayout::ApplyDXArray(rArgs);
-}
-}
-
// ===
static bool lcl_CharIsJoiner(sal_Unicode cChar)
diff --git a/vcl/inc/generic/glyphcache.hxx b/vcl/inc/generic/glyphcache.hxx
index e03e034..a7363f9 100644
[Libreoffice-commits] core.git: Branch 'libreoffice-4-1' - vcl/generic vcl/inc vcl/source
vcl/generic/glyphs/gcach_layout.cxx | 96
vcl/inc/generic/glyphcache.hxx |1
vcl/source/gdi/sallayout.cxx|4 -
3 files changed, 2 insertions(+), 99 deletions(-)
New commits:
commit 6a46cd31a44bd52fb9838a0d1937255a120a49ff
Author: Khaled Hosny khaledho...@eglug.org
Date: Thu May 23 09:34:27 2013 +0200
Fix left to right full justification
I was overloading ApplyDXArray() with a HarfBuzz specific implementation
because the GenericSalLayout one was screwing right to left kerning, but
it seems to have broken left to right full justifications. Since
mnXOffset was introduced a bit earlier to fix a similar issue, it can
now be used here as well to minimize the possible side effects.
Seems to work fine for both left to right and right to left text now,
but at least one of my Arabic tests is regressing, so might need some
tweaking.
Change-Id: I1239b0ec77a4978f981a480400a6d01cda18af79
diff --git a/vcl/generic/glyphs/gcach_layout.cxx
b/vcl/generic/glyphs/gcach_layout.cxx
index 07f9f76..6ac7fd4 100644
--- a/vcl/generic/glyphs/gcach_layout.cxx
+++ b/vcl/generic/glyphs/gcach_layout.cxx
@@ -90,102 +90,6 @@ void ServerFontLayout::AdjustLayout( ImplLayoutArgs rArgs )
}
}
-// apply adjustments to glyph advances, e.g. as a result of justification.
-void ServerFontLayout::ApplyDXArray(ImplLayoutArgs rArgs)
-{
-if (bUseHarfBuzz)
-{
-if (m_GlyphItems.empty())
-return;
-
-// determine cluster boundaries and x base offset
-const int nCharCount = rArgs.mnEndCharPos - rArgs.mnMinCharPos;
-int* pLogCluster = (int*)alloca(nCharCount * sizeof(int));
-size_t i;
-int n,p;
-long nBasePointX = -1;
-if (mnLayoutFlags SAL_LAYOUT_FOR_FALLBACK)
-nBasePointX = 0;
-for (p = 0; p nCharCount; ++p)
-pLogCluster[p] = -1;
-
-for (i = 0; i m_GlyphItems.size(); ++i)
-{
-n = m_GlyphItems[i].mnCharPos - rArgs.mnMinCharPos;
-if ((n 0) || (nCharCount = n))
-continue;
-if (pLogCluster[n] 0)
-pLogCluster[n] = i;
-if (nBasePointX 0)
-nBasePointX = m_GlyphItems[i].maLinearPos.X();
-}
-// retarget unresolved pLogCluster[n] to a glyph inside the cluster
-// TODO: better do it while the deleted-glyph markers are still there
-for (n = 0; n nCharCount; ++n)
-if ((p = pLogCluster[0]) = 0)
-break;
-if (n = nCharCount)
-return;
-for (n = 0; n nCharCount; ++n)
-{
-if (pLogCluster[n] 0)
-pLogCluster[n] = p;
-else
-p = pLogCluster[n];
-}
-
-// calculate adjusted cluster widths
-sal_Int32* pNewGlyphWidths = (sal_Int32*)alloca(m_GlyphItems.size() *
sizeof(sal_Int32));
-for (i = 0; i m_GlyphItems.size(); ++i)
-pNewGlyphWidths[i] = 0;
-
-bool bRTL;
-for (int nCharPos = p = -1; rArgs.GetNextPos(nCharPos, bRTL); )
-{
-n = nCharPos - rArgs.mnMinCharPos;
-if ((n 0) || (nCharCount = n)) continue;
-
-if (pLogCluster[n] = 0)
-p = pLogCluster[n];
-if (p = 0)
-{
-long nDelta = rArgs.mpDXArray[n];
-if(n 0)
-nDelta -= rArgs.mpDXArray[n - 1];
-pNewGlyphWidths[p] += nDelta * mnUnitsPerPixel;
-}
-}
-
-// move cluster positions using the adjusted widths
-long nDelta = 0;
-for (i = 0; i m_GlyphItems.size(); ++i)
-{
-if (m_GlyphItems[i].IsClusterStart())
-{
-// calculate original and adjusted cluster width
-int nOldClusterWidth = m_GlyphItems[i].mnNewWidth;
-int nNewClusterWidth = pNewGlyphWidths[i];
-size_t j;
-for (j = i; ++j m_GlyphItems.size(); )
-{
-if (m_GlyphItems[j].IsClusterStart())
-break;
-if (!m_GlyphItems[j].IsDiacritic()) // #i99367# ignore
diacritics
-nOldClusterWidth += m_GlyphItems[j].mnNewWidth;
-nNewClusterWidth += pNewGlyphWidths[j];
-}
-nDelta += nNewClusterWidth - nOldClusterWidth;
-}
-m_GlyphItems[i].mnNewWidth = pNewGlyphWidths[i];
-m_GlyphItems[i].maLinearPos.X() += nDelta;
-}
-}
-else
-{
-GenericSalLayout::ApplyDXArray(rArgs);
-}
-}
-
// ===
static bool lcl_CharIsJoiner(sal_Unicode cChar)
diff --git a/vcl/inc/generic/glyphcache.hxx b/vcl/inc/generic/glyphcache.hxx
index e03e034..a7363f9 100644
[Libreoffice-commits] core.git: vcl/source
vcl/source/gdi/sallayout.cxx |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 989225a89b109ca1497021dd4855a2450d13e8b9 Author: Khaled Hosny khaledho...@eglug.org Date: Thu May 23 22:32:14 2013 +0200 Fix improper glyph positioning with old fonts Apparently this second mnXOffset is not needed, further more it breaks some old Microsoft fonts. Change-Id: Ice033cb6bcb3f1bdfeef31a8406a7a2e5487da97 diff --git a/vcl/source/gdi/sallayout.cxx b/vcl/source/gdi/sallayout.cxx index e795090..31b01b9 100644 --- a/vcl/source/gdi/sallayout.cxx +++ b/vcl/source/gdi/sallayout.cxx @@ -1098,7 +1098,7 @@ void GenericSalLayout::ApplyDXArray( ImplLayoutArgs rArgs ) if( m_GlyphItems[j].IsClusterStart() ) break; if( !m_GlyphItems[j].IsDiacritic() ) // #i99367# ignore diacritics -nOldClusterWidth += m_GlyphItems[j].mnNewWidth - m_GlyphItems[j].mnXOffset; +nOldClusterWidth += m_GlyphItems[j].mnNewWidth; nNewClusterWidth += pNewGlyphWidths[j]; } const int nDiff = nNewClusterWidth - nOldClusterWidth; ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Branch 'libreoffice-4-1' - vcl/source
vcl/source/gdi/sallayout.cxx |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit cef3f3aac2f7a372e796deac4ee3e8155c5eb697 Author: Khaled Hosny khaledho...@eglug.org Date: Thu May 23 22:32:14 2013 +0200 Fix improper glyph positioning with old fonts Apparently this second mnXOffset is not needed, further more it breaks some old Microsoft fonts. Change-Id: Ice033cb6bcb3f1bdfeef31a8406a7a2e5487da97 diff --git a/vcl/source/gdi/sallayout.cxx b/vcl/source/gdi/sallayout.cxx index e795090..31b01b9 100644 --- a/vcl/source/gdi/sallayout.cxx +++ b/vcl/source/gdi/sallayout.cxx @@ -1098,7 +1098,7 @@ void GenericSalLayout::ApplyDXArray( ImplLayoutArgs rArgs ) if( m_GlyphItems[j].IsClusterStart() ) break; if( !m_GlyphItems[j].IsDiacritic() ) // #i99367# ignore diacritics -nOldClusterWidth += m_GlyphItems[j].mnNewWidth - m_GlyphItems[j].mnXOffset; +nOldClusterWidth += m_GlyphItems[j].mnNewWidth; nNewClusterWidth += pNewGlyphWidths[j]; } const int nDiff = nNewClusterWidth - nOldClusterWidth; ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Re: Line height depending on characters in that line
On Tue, Nov 20, 2012 at 05:57:12PM +0100, Lubos Lunak wrote: Hello, I'd need a little help from somebody who knows how exactly line height is computed. Specifically, create a new document, create a bullet list (2-3 items), and change it from bullets to 1. style (RMB-Bullets and numbering...-Numbering type - any of those). Doing this (visible when repeatedly hitting Ctrl+Z and Ctrl+Y) noticeably changes the height of all the lines. With MSWord there isn't such a big difference, leading to different formatting on .docx import in a specific bugreport I have. I have checked that this change is triggered by the bullet character being or not being present in the actual string representation of the line, so I assume that the bullet character from the OpenSymbol font is somehow higher than the rest, or that the font itself specifies this height. But I have no idea how this stuff works. What would be the proper way of fixing this? If you are on Linux, try setting env variable SAL_USE_NEW_LINEHEIGHT and see if it makes any difference (probably not, either case pullets shouldn't affect line height, but this is done in VCL which might be too late to distinguish content from non-content text). Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: A little info about ligatures and e.g. Calibri
On Tue, Feb 05, 2013 at 10:36:38AM +, Caolán McNamara wrote: On Sun, 2013-02-03 at 18:26 +0200, Khaled Hosny wrote: GTK have been enabling ligatures and other default OpenType features since ages (since before I started using computers :p), so probably the situation is not that bad. oh, I forgot, we also don't have proper cursor positions for ligatures either!, that's another epic lack. Cursor positioning inside ligatures seems to work for Arabic when using OpenType fonts, but not with Latin ligature when using Graphite fonts (couldn't find Arabic Graphite fonts with ligatures), so may be it is an issue with Graphite integration. Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: padmin/source
padmin/source/prtsetup.cxx | 145 -
padmin/source/prtsetup.hxx | 28
padmin/source/rtsetup.hrc | 11 ---
padmin/source/rtsetup.src | 76 ---
4 files changed, 260 deletions(-)
New commits:
commit 6230cdd2d8971147dcb629c8bd61daa1fefcb7c7
Author: Khaled Hosny khaledho...@eglug.org
Date: Tue Nov 26 14:40:07 2013 +0200
Drop font substitution tab page
The relevant VCL code will be dropped in the next commits.
Change-Id: Ieaa550d671fa43f2e5a96e2df7f256de2faf2fa4
Reviewed-on: https://gerrit.libreoffice.org/6857
Reviewed-by: Caolán McNamara caol...@redhat.com
Tested-by: Caolán McNamara caol...@redhat.com
diff --git a/padmin/source/prtsetup.cxx b/padmin/source/prtsetup.cxx
index 6588458..a91d43f 100644
--- a/padmin/source/prtsetup.cxx
+++ b/padmin/source/prtsetup.cxx
@@ -22,8 +22,6 @@
#include rtsetup.hrc
#include cmddlg.hxx
-#include vcl/fontmanager.hxx
-
#include osl/thread.h
#include officecfg/Office/Common.hxx
@@ -83,7 +81,6 @@ RTSDialog::RTSDialog( const PrinterInfo rJobData, const
OUString rPrinter, boo
, m_pPaperPage(NULL)
, m_pDevicePage(NULL)
, m_pOtherPage(NULL)
-, m_pFontSubstPage(NULL)
, m_pCommandPage(NULL)
, m_aInvalidString(PaResId(RID_RTS_RTSDIALOG_INVALID_TXT).toString())
{
@@ -97,7 +94,6 @@ RTSDialog::RTSDialog( const PrinterInfo rJobData, const
OUString rPrinter, boo
if( ! bAllPages )
{
m_pTabControl-RemovePage(m_pTabControl-GetPageId(other));
-m_pTabControl-RemovePage(m_pTabControl-GetPageId(font));
m_pTabControl-RemovePage(m_pTabControl-GetPageId(command));
}
else if( m_aJobData.m_aDriverName.startsWith(CUPS:) !
PrinterInfoManager::get().isCUPSDisabled() )
@@ -119,7 +115,6 @@ RTSDialog::~RTSDialog()
delete m_pPaperPage;
delete m_pDevicePage;
delete m_pOtherPage;
-delete m_pFontSubstPage;
delete m_pCommandPage;
}
@@ -141,8 +136,6 @@ IMPL_LINK( RTSDialog, ActivatePage, TabControl*, pTabCtrl )
pPage = m_pDevicePage = new RTSDevicePage( this );
else if (sPage == other)
pPage = m_pOtherPage = new RTSOtherPage( this );
-else if (sPage == font)
-pPage = m_pFontSubstPage = new RTSFontSubstPage( this );
else if (sPage == command)
pPage = m_pCommandPage = new RTSCommandPage( this );
if( pPage )
@@ -620,144 +613,6 @@ IMPL_LINK( RTSOtherPage, ClickBtnHdl, Button*, pButton )
return 0;
}
-// --
-
-/*
- * RTSFontSubstPage
- */
-
-RTSFontSubstPage::RTSFontSubstPage( RTSDialog* pParent ) :
-TabPage( pParent-m_pTabControl, PaResId( RID_RTS_FONTSUBSTPAGE ) ),
-m_pParent( pParent ),
-m_aSubstitutionsText( this, PaResId( RID_RTS_FS_SUBST_TXT ) ),
-m_aSubstitutionsBox( this, PaResId( RID_RTS_FS_SUBST_BOX ) ),
-m_aFromFontText( this, PaResId( RID_RTS_FS_FROM_TXT ) ),
-m_aFromFontBox( this, PaResId( RID_RTS_FS_FROM_BOX ) ),
-m_aToFontText( this, PaResId( RID_RTS_FS_TO_TXT ) ),
-m_aToFontBox( this, PaResId( RID_RTS_FS_TO_BOX ) ),
-m_aAddButton( this, PaResId( RID_RTS_FS_ADD_BTN ) ),
-m_aRemoveButton( this, PaResId( RID_RTS_FS_REMOVE_BTN ) ),
-m_aEnableBox( this, PaResId( RID_RTS_FS_ENABLE_BTN ) )
-{
-FreeResource();
-
-// fill to box
-PrintFontManager rFontManager = PrintFontManager::get();
-::std::list FastPrintFontInfo aFonts;
-rFontManager.getFontListWithFastInfo( aFonts,
m_pParent-m_aJobData.m_pParser );
-::std::list FastPrintFontInfo ::const_iterator it;
-::boost::unordered_map OUString, int, OUStringHash aToMap, aFromMap;
-for( it = aFonts.begin(); it != aFonts.end(); ++it )
-{
-if( it-m_eType == fonttype::Builtin )
-{
-if( aToMap.find( it-m_aFamilyName ) == aToMap.end() )
-{
-m_aToFontBox.InsertEntry( it-m_aFamilyName );
-aToMap[ it-m_aFamilyName ] = 1;
-}
-}
-else
-{
-if( aFromMap.find( it-m_aFamilyName ) == aFromMap.end() )
-{
-m_aFromFontBox.InsertEntry( it-m_aFamilyName );
-aFromMap[ it-m_aFamilyName ] = 1;
-}
-}
-}
-
-m_aEnableBox.Check( m_pParent-m_aJobData.m_bPerformFontSubstitution );
-m_aRemoveButton.Enable( sal_False );
-if( ! m_pParent-m_aJobData.m_bPerformFontSubstitution )
-{
-m_aSubstitutionsBox.Enable( sal_False );
-m_aSubstitutionsText.Enable( sal_False );
-m_aAddButton.Enable( sal_False );
-m_aToFontBox.Enable( sal_False );
-m_aToFontText.Enable( sal_False );
-m_aFromFontBox.Enable( sal_False );
-m_aFromFontText.Enable( sal_False );
-}
-
-update();
-
-m_aAddButton.SetClickHdl( LINK( this, RTSFontSubstPage
[Libreoffice-commits] core.git: include/vcl psprint_config/configuration vcl/generic vcl/inc vcl/null vcl/unx
include/vcl/printerinfomanager.hxx | 21 ---
psprint_config/configuration/psprint.conf | 32 -
vcl/generic/print/common_gfx.cxx | 25
vcl/generic/print/genpspgraphics.cxx |8 -
vcl/generic/print/printerjob.cxx | 30 +---
vcl/generic/print/text_gfx.cxx | 62 +++---
vcl/inc/generic/printergfx.hxx | 14 --
vcl/null/printerinfomanager.cxx|5
vcl/unx/generic/printer/printerinfomanager.cxx | 153 -
9 files changed, 42 insertions(+), 308 deletions(-)
New commits:
commit 24657548a71355e1a087b87d725647793785daa9
Author: Khaled Hosny khaledho...@eglug.org
Date: Tue Nov 26 16:37:16 2013 +0200
Don't perform printer font substitution
The so called printer resident fonts is a relic of a bygone era, when
life was simple and there was only ASCII and Type1 fonts.
It is just broken by design these days, offers nothing useful and can go
wrong in many ways. Since 1f3a91cf2ace315fb332c0149808a2433eb9ae71 this
feature is disabled by default anyway, so scrap this code to make room
for some long due cleanup.
Change-Id: Id124b2cad1a484099701a885c4d96e6a12af8d9a
Reviewed-on: https://gerrit.libreoffice.org/6858
Reviewed-by: Caolán McNamara caol...@redhat.com
Tested-by: Caolán McNamara caol...@redhat.com
diff --git a/include/vcl/printerinfomanager.hxx
b/include/vcl/printerinfomanager.hxx
index 96e7846..b431fad 100644
--- a/include/vcl/printerinfomanager.hxx
+++ b/include/vcl/printerinfomanager.hxx
@@ -50,24 +50,9 @@ struct PrinterInfo : JobData
// a list of special features separated by ',' not used by psprint
// but assigned from the outside (currently for
fax,pdf=,autoqueue,external_dialog)
OUString m_aFeatures;
-// a mapping of fonts to other fonts.
-// this provides a method for the user
-// to replace arbitrary fonts by printer builtin fonts
-// currently this is only a mapping between font names
-// assuming that only adbobe standard encoding fonts are
-// built into the printer. in future it may be necessary
-// to map to a font name and UCS2 vector which should be mapped
-// this vector is currently implicitly given by the adobe
-// standard encoding
-boolm_bPerformFontSubstitution;
-boost::unordered_map OUString, OUString, OUStringHash
-m_aFontSubstitutes;
-boost::unordered_map fontID, fontID
-m_aFontSubstitutions;
PrinterInfo() :
-JobData(),
-m_bPerformFontSubstitution( false )
+JobData()
{}
};
@@ -133,10 +118,6 @@ protected:
virtual void initialize();
-// fill in font substitutions
-// the resulting boost::unordered_map maps from source to target font ids
-void fillFontSubstitutions( PrinterInfo rInfo ) const;
-
// fill default paper if not configured in config file
// default paper is e.g. locale dependent
// if a paper is already set it will not be overwritten
diff --git a/psprint_config/configuration/psprint.conf
b/psprint_config/configuration/psprint.conf
index b69bfe1..d6c333b 100644
--- a/psprint_config/configuration/psprint.conf
+++ b/psprint_config/configuration/psprint.conf
@@ -61,23 +61,6 @@
; if key is absent the default value is driver specific
; PPD_PageSize=A4
-; Note: the following two key types are in the global section to provide
-; defaults for newly added printers.
-; PerformFontSubstitution: whether to replace downloadable fonts
-; with resident fonts or not
-PerformFontSubstitution=false
-
-; SubstFont_downloadable font: the resident font to replace
-; downloadable font if PerformFontSubstitution is true
-SubstFont_Helmet=Helvetica
-SubstFont_Albany=Helvetica
-SubstFont_Courier New=Courier
-SubstFont_Arial=Helvetica
-SubstFont_Times New Roman=Times
-SubstFont_Thorndale=Times
-SubstFont_Timmons=Times
-SubstFont_Cumberland=Courier
-
[Generic Printer]
; for every printer a group with at least the keys
@@ -114,18 +97,3 @@ Command=
; external_dialog to notify that the print command of a printer will show a
dialog
; and therefore the application should not show its own dialog.
;Features=
-
-; PerformFontSubstitution: whether to replace downloadable fonts
-; with resident fonts or not
-PerformFontSubstitution=false
-
-; SubstFont_downloadable font: the resident font to replace
-; downloadable font if PerformFontSubstitution is true
-SubstFont_Helmet=Helvetica
-SubstFont_Albany=Helvetica
-SubstFont_Courier New=Courier
-SubstFont_Arial=Helvetica
-SubstFont_Times New Roman=Times
-SubstFont_Thorndale=Times
-SubstFont_Timmons=Times
-SubstFont_Cumberland=Courier
diff --git a/vcl/generic/print/common_gfx.cxx b/vcl/generic/print/common_gfx.cxx
index 0582537..851739a 100644
--- a/vcl/generic/print/common_gfx.cxx
+++ b/vcl
