[Issue 88613] Canvas: cairo-based font rendering
by hdu＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=88613
------- Additional comments from hdu(a)openoffice.org Mon Apr 28 10:45:31 +0000 2008 -------
> With 1 line of platform-specific code... This replaces the hundreds of lines of code of all the
DrawText, DrawTextArray functions
Great! If text justification, text decorations (like underline/strikethrough/emphasis marks), multi-line
controls, etc. still work I'm quite impressed. Also supporting all the exotic use cases for rendering old
metafiles would be nice.
> Any suggestions on how to get the glyph-by-glyph information with
> rendering::XTextLayout and/or from VCL is greatly appreciated
use SalLayout::GetNextGlyphs()
that interface is a little ad-hoc though and will be replaced by a container/iterator style interface, but
the changes for users of that call will be trivial
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
16 years
[Issue 88613] Canvas: cairo-based font rendering
by mox＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=88613
User mox changed the following:
What |Old value |New value
================================================================================
Status|RESOLVED |REOPENED
--------------------------------------------------------------------------------
Resolution|LATER |
--------------------------------------------------------------------------------
------- Additional comments from mox(a)openoffice.org Sun Apr 27 12:40:00 +0000 2008 -------
With the WIP2 patch, I'm able to get fonts rendered in cairo with correct
colors, size, bold/italic, underline, and shadow. Underlines and shadows seem to
be rendered manually by the Canvas (not by the font).
The patch is still using string based rendering (not glyph by glyph), so
advanced layouting is missing.
I'm getting the native font ID (with all the styling already set) for the
selected VCL Font, and rendering with that native font. I needed to add an
additional function:
sal_IntPtr OutputDevice::GetFontId( const Font& rFont, float
fExactHeight );
to get the native font id. I guess the long term solution would be to add struct
SystemFontData to vcl/inc/vcl/sysdata.hxx and fill it appropriately.
So on Mac, I can get cairo-rendered text with e.g. Zapfino font showing up
nicely :) With 1 line of platform-specific code... This replaces the hundreds of
lines of code of all the DrawText, DrawTextArray functions in vcl/source and
their platform specific implementations.
Any suggestions on how to get the glyph-by-glyph information with
rendering::XTextLayout and/or from VCL is greatly appreciated.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
16 years
[Issue 88613] Canvas: cairo-based font rendering
by mox＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=88613
User mox changed the following:
What |Old value |New value
================================================================================
Attachment is patch| |Created an attachment (id=
| |53225)
Work in Progress -
| |v2
--------------------------------------------------------------------------------
------- Additional comments from mox(a)openoffice.org Sun Apr 27 12:24:18 +0000 2008 -------
Created an attachment (id=53225)
Work in Progress - v2
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
16 years
[Bug 444238] New: freetype thinks fonts hrger*.pfa are broken
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=444238
Summary: freetype thinks fonts hrger*.pfa are broken
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: freetype
AssignedTo: besfahbo(a)redhat.com
ReportedBy: keiths(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com
Description of problem:
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
16 years
[Issue 88613] Canvas: cairo-based font rendering
by mox＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=88613
------- Additional comments from mox(a)openoffice.org Thu Apr 24 19:03:16 +0000 2008 -------
Hi hdu, thanks for the comments. I also don't want this issue to become endless
tug war, so I just clarify some things. Note that I don't really have a perfect
solution to offer, neither I'm expecting the text layout to be solved anytime soon.
...
Yes, the quartz failing is just a bug, and does not need the level of changes
that I'm describing here.
The core of the discussion is that OpenOffice.org has been and in many respects
is still not proactive in integrating with the other open source projects,
causing OpenOffice.org to remain a huge, non-shared (with other projects)
codebase. This means OOo needs to have e.g. it's own set of developers for all
of text rendering and fonts, because no other project is working on that code.
The reason for working with cairo based font rendering and layout is the same as
using cairo library anywhere in the OOo:
Yes, OOo could do everything by itself with directly using functions of native
platforms + OOo specific crossplatform layer.
However, OOo can also use cairo (among others) as the crossplatform layer, that
can REMOVE the code that OOo currently has. While it creates another layer of
API, if it (eventually) can become the only API (just like Mozilla Firefox 3
has), then the rest of the OOo code can be optimized for that API. And OOo
developers can also work with cairo developers to improve that library (which
already pretty good exactly thanks to contributions from MULTIPLE independent
projects).
=> more shared code, less OOo-specific code.
...
For graphics rendering cairo is the unquestioned choice. It seems to be a good
choice for font rendering too. To me, text layout is completely unknown area. I
do know that pango nowadays uses harfbuzz, which is a collaborative project
between Gnome and KDE. So that's pretty good coverage on UNIX/X11.
However, high quality crossplatform support is the key here. Only X11 is not enough.
...
So currently I'm targetting just font rendering, and hoping a good layout
solution comes up some day.
And I'm not saying things cannot go to the other direction too. For example on
UNIX, hunspell has originated from inside OOo and now distributions are
standardising on it, and replacing the aspell/pspell/myspell alternatives.
That's not crossplatform, but it's a nice step forward.
If OOo's text layout is superior to others, why not create a crossplatform
textlayout module -- with "libtextlayout" -library that can then be used by
other projects (and is nicely isolated for OOo)? It would need to become an
independent hunspell-like "sourceforge" project (i.e. outside of OOo CWS hassles
and schedules) to truly enable sharing and collaboration.
...
Open source gives best results when you are proactive with ways of sharing and
collaboration.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
16 years
[Bug 433584] New: [ml_IN] Traditional scripts (smc-fonts) to be included in fonts-indic
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=433584
Summary: [ml_IN] Traditional scripts (smc-fonts) to be included
in fonts-indic
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: fonts-indic
AssignedTo: rbhalera(a)redhat.com
ReportedBy: apeter(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: aalam@redhat.com,eng-i18n-bugs(a)redhat.com,fedora-fonts-
bugs-list@redhat.com,pravi.a(a)ippimail.com
Description of problem:
Majority of Kerala community work using traditional script fonts. Thus there is
a huge demand to include the popular traditional scripts like Rachana, Meera in
fonts-indic package. There is an archive called smc-fonts-malayalam in smc
upstream containing Rachana, Meera, Mal0tf fonts. Rachana, Meera are traditional
scripts and Mal0tf is based on a new script. Since all these fonts are popular
and in great demand from community, these fonts also have to be included in
fonts-indic.
smc-fonts-malayalam available at:
http://download.savannah.nongnu.org/releases/smc/fedora/8/SRPMS/
Thanks
Ani
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
16 years
[Issue 88613] Canvas: cairo-based font rendering
by hdu＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=88613
User hdu changed the following:
What |Old value |New value
================================================================================
Status|NEW |RESOLVED
--------------------------------------------------------------------------------
Resolution| |LATER
--------------------------------------------------------------------------------
Target milestone|--- |OOo Later
--------------------------------------------------------------------------------
------- Additional comments from hdu(a)openoffice.org Thu Apr 24 08:54:15 +0000 2008 -------
The original issue here is that the current OOo-Canvas based on cairoquartz doesn't render text yet.
Since Quartz can render beautiful text in its sleep if it gets a proper Quartz CGContext, I'm very sure
this is a bug in the cairoquartz01 child workspace. I'll debug into it when I'll resync CWS
aquabmpfixes01 to something >= DEV300_m6.
Other than that I'm afraid this issuezilla item is already drifting way off topic. I'll comment only ONCE
on the other suggestions here. If needed please open focussed issues.
---
Great ideas here! Thanks! I'll get right on it!
On a second thought some Pango related questions come to mind:
P1.) is Pango's layout engine that much better than Apple's native ATSUI or CoreText?
P2.) is it at least that much better than Window's native Uniscribe?
P3.) what are the specific benefits over ICU's layout engine that OOo uses on Unix?
do specific http://bugs.icu-project.org/trac bugs have showstopper qualities?
P4.) isn't Pango being obsoleted by HarfBuzz / Graphite on Unix?
P5.) wouldn't we loose the "justified text" feature, that some/most author prefer?
Also some related questions about Cairo's text rendering:
C1.) is it that much better than Apple's native ATSUI or CoreText?
C2.) is it at least that much better than Window's native Uniscribe?
C3.) since CWS cairotext01 (http://eis.services.openoffice.org/EIS2/cws.ShowCWS?
Path=SRC680%2Fcairotext01) our Unix port supports it already
It used to be better because of subpixel-rendering, but nowadays distributions switched exactly
THAT feature off, so what are the remaining killer features?
Speaking of text rendering on Unix I'd like to mention that during the live-time of OOo's unix codebase
Xft (now unmaintained), STSF (now unmaintained) and "pure" XLFD were "the right thing to do" de jour.
The answers to P1/P2/C1/C2 are such that even Pango itself just wraps the native layout engines. And
since OOo uses UTF-16, Pango's interface is UTF-8 and the native layout engines are using UTF-16
again the roundtrip would be a nice way to warm up the cpu. For nothing! But getting rid of native text
justification and losing access to the real layout engines for their potential advanced typography
features.
I'd also like to mention that a major difference between a browser and a word processor is that a
browser aims especially for screen rendering whereas a word processor usually targets a non-screen
device. In other words: most people would complain if their document's pages re-flowed when they
changed the word processors zoom level (which corresponds to a Browser's default text size setting).
This difference is responsible for application-layer problems like issue 88539 (Writer rendering), issue
51508 (Calc rendering) or issue #thb# (Impress rendering). Since people especially mean these issues
when they comment on OOo text rendering problems they would be surprised that even if we did the
herculean task to rip out the guts of GSL to replace it with the "recommended stack" these problems
(and other niceties like issue 79878!) would remain just as before.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
16 years
[Issue 54944] Provide way to mark forced font replacement
by nmailhot＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=54944
User nmailhot changed the following:
What |Old value |New value
================================================================================
CC|'hdu,jeongkyu,maxweber,mey|'fedorafonts,hdu,jeongkyu,
|wer,pl,ssa,us' |maxweber,meywer,pl,ssa,us'
--------------------------------------------------------------------------------
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
16 years
[Issue 88583] AutoCorrection changes Font
by va＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=88583
User va changed the following:
What |Old value |New value
================================================================================
Status|STARTED |RESOLVED
--------------------------------------------------------------------------------
Resolution| |FIXED
--------------------------------------------------------------------------------
------- Additional comments from va(a)openoffice.org Wed Apr 23 13:58:34 +0000 2008 -------
.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
16 years
