bugThe FreeType Project - Bugs: bug #28678, FreeType not preserving Type 1...

 
 

bug #28678: FreeType not preserving Type 1 vertical advance values

Submitted by:  Kenneth Sharp <kens>
Submitted on:  Mon 18 Jan 2010 04:28:02 PM UTC  
 
Severity: 3 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: 2.3.12

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 11 Feb 2010 09:24:58 AM UTC, comment #43:

Looks good Werner, I pulled a fresh copy from GIT, rebuilt and ran one of my test files. The resulting glyphs get the vertical advance applied as expected. Many thanks!

Kenneth Sharp <kens>
Project Member
Wed 10 Feb 2010 06:16:09 AM UTC, comment #42:

I've applied your changes the git repository. Please check. Thanks a lot for your intensive work on this problem!

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 04 Feb 2010 03:18:31 PM UTC, comment #41:

The increased structure size should only be capable of provoking a SEGV if the application is expecting the increased size structure (modified .h file), but is linked against an older library returning a pointer to a smaller size structure. In this case the application might read off the end of the data.

If a newer library is linked to an older application (expecting the shorter structure) there should not be any problems.

That's what I meant by 'binary compatible', linking a new library to an old application.

Attached is a zip file with diffs for ftincrem.h, cffgload.c, cidgload.c, t1gload.c and ttgload.c. This is following my understanding of Werner's suggestions below.

1) Undo the double call to get_glyph_metrics (vertical and horizontal) for cff, cid and t1 fonts.

2) Add a new field to the incremental metrics structure to hold the vertical component of the advance (could be better named probably)

3) Initialise the value from builder.advance.y in t1gload.c and cidgload.c, set the field to 0 in cffgload.c and ttgload.c. NB CFF fonts do not permit this quirky vertical advance, they always have a horizontal advance.

3) In t1gload.c alter the #if 0 #else #endif block where the advance values are loaded from the vertical metrics from the interpreter (builder.advance.y) to an if/else construct checking load_flags and FT_LOAD_VERTICAL_LAYOUT. Invent metrics if true, use the parsed vertical metric otherwise.

4) In t1gload.c, cffgload.c and cidgload.c, guard the call to synthesize_vertical_metrics with the same load_flags check.

I checked the compatibility in a limited fashion by building GS with an old include file, and linking against the modified library (modified the metrics record).

As expected this caused no problems, on either Linux or Windows. It is however a very limited test.

I'm just going to start a (lengthy) regression test to see if this introduces any new problems, but I don't expect it to.

Sorry for the slow reply, I'm trying to make sure this patch is correct and doesn't cause any problems.

Hmm, still running regression check, mostly its OK but I've seen a file with a problem, I'm not sure yet if this is a GS problem or the result of the changes to FT.

(file #19619)

Kenneth Sharp <kens>
Project Member
Thu 04 Feb 2010 01:04:10 PM UTC, comment #40:

>> However both of these fell 'clunky' to me, especially the
>> reliance on the incremental interface. I feel it would be
>> better to have the value available as part of the
>> FT_Glyph_Metrics structure.
>
>Well, does the above convince you?


I hesitate to extend FT_Glyph_Metrics, because the troubles
caused by its incompatibility is not easy to spot: the exist/
inexist of the function is quickly reported by the linker, but
the different sized structure may or may not cause unexpected
SEGV.

Anyway, I wrote a patch to review how the difference appears.
Attached is an experimental patch to extend advance in
FT_Glyph_Metrics to hold 2D advance. For easier checking,
the patch is to GIT 2010-Jan-23 (just before Ken's patch),
not to GIT HEAD. The rewriting is not so difficult, just insert
lines that copies right to left.

Also I attached another patch for GS (SVN rev 10675) to use
extended FT_Glyph_Metric. The result is also attached.

(file #19616, file #19617, file #19618)

suzuki toshiya <mpsuzuki>
Project Administrator
Thu 04 Feb 2010 08:19:13 AM UTC, comment #39:

This is the by far most discussed topic ever in the whole FreeType bug database :-)

> The first change to 'fix' sbw vertical advance was in
> t1gload.c around line 99, the incremental interface only.
> Having parsed the sbw values out during CharString
> interpretation, the code here explicitly set
> decoder->builder.advance.y (which is where 'wy' is stored)
> to 0.


This is OK.

> My first patch added a new field to the
> FT_Incremental_MetricsRec structure and recorded the value
> there. Later Werner pointed out that it might be better to
> do two calls, one for vertical and one for horizontal metrics.
> This now seems incorrect.


Yes, it was my mistake to ask you for changing this.

> Anyway, after solving the overwrite with 0 when using the
> incremental interface, the next change is again in t1gload.c
> around line 415:
>
> #if 0
> /* make up vertical ones */
> metrics->vertAdvance = ( face->type1.font_bbox.yMax -
> face->type1.font_bbox.yMin ) >> 16;
> glyph->root.linearVertAdvance = metrics->vertAdvance;
> #else
> metrics->vertAdvance =
> FIXED_TO_INT( decoder.builder.advance.y );
> glyph->root.linearVertAdvance =
> FIXED_TO_INT( decoder.builder.advance.y );
> #endif
>
> The original code is the #if 0 block, as you can see it
> invented a linear advance and wrote it into the metrics
> structure.


This should be changed: Instead of

#if 0 ... #else ... #endif

it should be

if (FT_LOAD_VERTICAL_LAYOUT) {...} else {...}.

> Because there was no other way to return the advance.y value,
> I chose to write it into the linearVertAdvance, this too may
> be a mistake.


I think it's not a mistake. Provided it is correctly scaled, it is exactly the correct value.

> Finally this value was further overwritten in t1gload.c by
> the synthesize_vertical_metrics call around line 486 if the
> vertical advance was 0.


This is a bug. It should be again guarded with a check to
FT_LOAD_VERTICAL_LAYOUT.

> We then track back up into FT_Load_Glyph at line 702. If we
> have set FT_LOAD_VERTICAL_LAYOUT then we use the vertAdvance
> from the metrics as the slot->advance.y (and set x to 0)
> otherwise we use the horiAdvance to set the slot->advance.x
> (and set y to 0).


This is correct since the `advance' field is just a shorthand. Some time ago I've better documented that (at least I think so).

> FT_Load_Glyph returns us to the calling application. Now, the
> horizontal component of the advance is available in
> 'ft_face->glyph->metrics.horiAdvance', and it seemed logical
> to me that the vertical advance should be in
> ft_face->glyph->metrics.vertAdvance, which is where it
> currently is.


Full agreement here.

> I think FreeType should return that 'wy' value somewhere
> readily available and to me that would seem to be in the
> metrics structure.


Yep. `wy' should be stored as you've implemented it -- for the horizontal layout. If the user requests vertical layout I still think that the advance values should be synthesized. We can make a notice in the docs accordingly.

> Changing the incremental interface metrics record would not
> break binary compatibility, provided the new field was added
> as the final value in the structure.


Good to hear this confirmation.

> So, I can live with a change which involves a new API call,


I can't :-)

> or a change to the FT_Incremental_MetricsRec structure and
> record the values during the get_glyph_metrics callback.


I'm now confident that this your original suggestion is the way to go.

> However both of these fell 'clunky' to me, especially the
> reliance on the incremental interface. I feel it would be
> better to have the value available as part of the
> FT_Glyph_Metrics structure.


Well, does the above convince you?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 02 Feb 2010 02:42:23 PM UTC, comment #38:

The first change to 'fix' sbw vertical advance was in t1gload.c
around line 99, the incremental interface only. Having parsed the sbw values out during CharString interpretation, the code here explicitly set decoder->builder.advance.y (which is where 'wy' is stored) to 0.

My first patch added a new field to the FT_Incremental_MetricsRec structure and recorded the value there. Later Werner pointed out that it might be better to do two calls, one for vertical and one for horizontal metrics. This now seems incorrect.

Anyway, after solving the overwrite with 0 when using the incremental interface, the next change is again in t1gload.c around line 415:

#if 0
/* make up vertical ones */
metrics->vertAdvance = ( face->type1.font_bbox.yMax -
face->type1.font_bbox.yMin ) >> 16;
glyph->root.linearVertAdvance = metrics->vertAdvance;
#else
metrics->vertAdvance =
FIXED_TO_INT( decoder.builder.advance.y );
glyph->root.linearVertAdvance =
FIXED_TO_INT( decoder.builder.advance.y );
#endif

The original code is the #if 0 block, as you can see it invented a linear advance and wrote it into the metrics structure.

Because there was no other way to return the advance.y value, I chose to write it into the linearVertAdvance, this too may be a mistake.

Finally this value was further overwritten in t1gload.c by the synthesize_vertical_metrics call around line 486 if the vertical advance was 0.

Please note that, although Ghostscript is using the incremental interface, neither of these latter changes, nor the general problem, is specific to the incremental interface. In the original code we have discarded or overwritten the 'wy' value by now.

We then track back up into FT_Load_Glyph at line 702. If we have set FT_LOAD_VERTICAL_LAYOUT then we use the vertAdvance from the metrics as the slot->advance.y (and set x to 0) otherwise we use the horiAdvance to set the slot->advance.x (and set y to 0).

We then calculate the 'linear advance' (in passing, there do seem to be a lot of different metrics floating about in here).

FT_Load_Glyph returns us to the calling application. Now, the horizontal component of the advance is available in 'ft_face->glyph->metrics.horiAdvance', and it seemed logical to me that the vertical advance should be in ft_face->glyph->metrics.vertAdvance, which is where it currently is.

Enough history....

I don't think its a great idea to limit the availability of the 'wy' parameter to the get_glyph_metrics callback, as this is only available when the incremental interface is in use, and puts a burden on the calling application to record that value (even if it has no wish to modify the metrics). I think FreeType should return that 'wy' value somewhere readily available and to me that would seem to be in the metrics structure.

Changing the glyph->metrics (FT_Glyph_Metrics) structure would break binary compatibility with earlier versions of FreeType, as this structure is stored inside a larger structure, so offsets would be incorrect.

Changing the incremental interface metrics record would not break binary compatibility, provided the new field was added as the final value in the structure. Applications compiled with the old structure would simply be unable to access the member. Since the structure is passed by pointer there should be no other effects.

So, I can live with a change which involves a new API call, or a change to the FT_Incremental_MetricsRec structure and record the values during the get_glyph_metrics callback. However both of these fell 'clunky' to me, especially the reliance on the incremental interface. I feel it would be better to have the value available as part of the FT_Glyph_Metrics structure.

But I'll take anything I can get......

Kenneth Sharp <kens>
Project Member
Tue 02 Feb 2010 01:52:41 PM UTC, comment #37:

Attached is another patch to hold sbw parameters in T1_GlyphSlot
and access it via new function FT_Get_PS_SbW_Params(). The outline
is following:

1) Extend T1_GlyphSlot to backup original sbw parameters
that was obtained during T1 CharString decoding.
The metrics are overwritten by existing vertical metric
synthesizer.

2) Add an internal function to retrieve original sbw
parameters backuped in T1_GlyphSlot.

3) Call the function via service API.

This is just a proof of idea, the design of FT_Get_PS_SbW_Params()
should be reconsidered. If binary compatibility of incremental interface
is important, it might be useful.

Werner, should I check the prebuilt binaries of Linux &
BSD variants?

(file #19607)

suzuki toshiya <mpsuzuki>
Project Administrator
Tue 02 Feb 2010 01:12:39 PM UTC, comment #36:

Sorry for not answering earlier, I was abroad.

Your very first idea was the right one, namely to add a new field for storing the vertical component of the 2D advance vector (which I consider is for horizontal writing only). I was mistaken. However, it seems that adding a new field possibly breaks binary compatibility. Can you check this, please? On the other hand, I believe that only GhostScript uses the incremental interface, so it wouldn't be a very big problem.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 02 Feb 2010 11:53:04 AM UTC, comment #35:

Seems that the wx value has always been returned by the type 1 interpreter in the decoder->builder.advance.y field.

In the past this was overwritten by the incremental interface code when it called the get_glyph_metrics callback (see t1gload.c, T1_Parse_Glyph_And_Get_Char_String, line 100). The code here was updated for me by Werner to call the get_glyph_metrics callback twice, once for horizontal metrics and once for vertical metrics. Before that it used to unconditionally set the vertical advance value to 0.

Now that the overwrite no longer occurs the value of decoder->builder.advance.y is the wy value supplied to the sbw operator. All that is required is to return that value to the caller.

Kenneth Sharp <kens>
Project Member
Tue 02 Feb 2010 09:20:15 AM UTC, comment #34:

>(Ken, if your second patchset is applied, the properties passed
>by the metric is identical with the properties defined by "sbw"?
>If modified, other naming would be better to avoid confusion)


Toshiya, I believe a previous patch stored the 'wy' value from sbw in a vertical advance field in FT. I'm afraid I can't remember where that was done but I'll try and locate it.

The patches I've been supplying in this thread do two things, firstly add a second call to the get_glyph_metrics callback (type 1, CFF and CID fonts) so that the incremental interface has the opportunity to modify the vertical advance (it already can modify the horizontal advance). These changes can probably stay 'as is' they are independent of the actual issue for me.

The second change is the one provoking all the discussion. This one removed the line in synthesize_vertical_metrics which replaced the value from the interpreter with a 'heuristic' value. This is the change we need to find a different way to achieve.

Kenneth Sharp <kens>
Project Member
Mon 01 Feb 2010 05:52:22 PM UTC, comment #33:

>So lets leave aside discussions of metrics.


OK. For a long time, I'm wondering how to use "sbw" operator
because of the lack of sample font. I appreciate SaGS creates
such and show how it works.

I have no objection to the request of the API to retrieve
the values specified by "sbw". It is missing in current FT2,
and it is important for the clients to compute the shift of
current point from current glyph to next glyph, especially
for the font designed to shift the current point intricately
as testing PostScript (bug689267.ps).

# Werner, please check the content of
# http://bugs.ghostscript.com/attachment.cgi?id=3313&action=view
# it creates PS Type1 font with various 2D shifts of current
# points by "hsbw" & "sbw", and use it as if it were
# conventional Latin fonts for horizontal writing mode.
# But the moving of current point is very complex.

Again, I have no objection to this request, but I'm not sure
if they are consistent with what FT2 had been providing as
"metrics". I'm afraid that FT2 is designed to provide metrics
with the consideration of horizontal/vertical writing-mode
as conventional TrueType.

I think, conventional TrueType supports completely
horizontal shift of current point for horizontal writing mode,
and completely vertical shift of current point for vertical
writing mode. So, FT_Incremental_MetricRec has only 1D
property for advance. In addition, TrueType font is aware
of horizontal/vertical writing mode, and stores horizontal/vertical
advances as independent properties.

On the other hand, within the scope of PS Type1 font format,
the font format is not aware of any writing mode, but supports
slanted shift. To specify the writing mode correctly (e.g. layout
CJK glyph in PS Type1 font with horizontal shift of current point),
the PostScript renderer should add extra shift(s) of current point.
# PostScript Language Reference 3rd edition p. 347, FIGURE 5.7.
I think what the user of vertical metrics synthesizer expect is such,
not raw 2D vector defined by "sbw".

--

In summary, I want to change the macro name to disable the
vertical metrics synthesizer, something like:
FT_PARAM_TAG_GET_PS_SBW_VIA_METRIC
(Ken, if your second patchset is applied, the properties passed
by the metric is identical with the properties defined by "sbw"?
If modified, other naming would be better to avoid confusion)

Werner, how do you think of?

suzuki toshiya <mpsuzuki>
Project Administrator
Mon 01 Feb 2010 03:27:12 PM UTC, comment #32:

>At present, the request looks like "GS expects that FT2 returns
>some values fitting to existing algorithm in GS, instead of
>synthesized vertical metrics that don't fit to existing
>algorithm in GS".


This isn't really anything to do with Ghostscript's algorithms, its an absolute requirement of any PostScript interpreter. If you like we could change the request text to 'allow retrieval of vertical component of type 1 width vector' or something similar.

At the moment this value is what I would consider to be the vertical advance metric for the glyph. I don't really care what its called though. It is important information for a PostScript interpreter as it is a directive from the glyph program to the interpreter to re-position the current point after rendering the glyph.

Currently that information is either not returned at all, or if it is intended to be returned by the vertical advance of the metrics structure (as would seem reasonable by symmetry, because the horizontal component is returned in the horizontal advance field) then the information is being overwritten by the synthesis of the vertical metrics.

As it stands, its impossible to get the information required to correctly re-position the current point for a glyph using sbw using the FreeType interface (at least, as far as I can tell).

So lets leave aside discussions of metrics. My goal is to retrieve, in any possible way, the 'wy' argument to the 'sbw' operator when used in a type 1 glyph. That's what I need, and I really don't mind how its achieved, whether by using the metrics structure or by some other method.

Regarding vertical and horizontal writing, there is no such distinction in PostScript or the type 1 font structure. When a glyph is rendered the current point is advanced by the wx and wy values of the width (either of which may be zero).

Glyphs may have positive or negative width values, and may have zero values for either of the x or y components. Thus a glyph can advance left-to-right, right-to-left, top-to-bottom, bottom-to-top or any combination. A font may contain glyphs which advance in different directions.

When rendering consecutive glyphs the interpreter simply repositions the current point after each glyph as directed by the glyph program. If the glyphs are 'vertical writing' then the current point will move vertically, if the glyphs are horizontal the current point will move vertically. Then the next glyph is rendered and the process repeated. But the PostScript program can always position glyphs individually. However neither the PostScript language nor the type 1 interpreter has a fixed 'directionality', although its certainly true that there is a bias throughout the language towards Latin text.

I'm not sure what further information you want regarding how to use the values supplied to sbw. The information is given in the Type 1 font specification, here's some summary text.

The left side bearing moves the initial point in the glyph co-ordinate system to the 'left side bearing point' this is the initial point of the glyph. In effect its a 'move to' instruction but a special one because the move is not considered as part of the path describing the glyph. As far as I can tell FreeType already uses the side bearing to position the initial point, so this doesn't need any further treatment.

Note that this is always the leftmost point, the spec says (p22 of my rather elderly copy, under 'Character Geography'):

"The left sidebearing is a vector, generally horizontal to the right,from the origin to a point whose x coordinate coincides with the x coordinate of the leftmost filled part of the character."

Also "The left sidebearing point is the coordinate at which the left side-bearing vector terminates. They coordinate of the left sidebearing point is almost always 0. (There are always exceptions in font program design, and there can be conditions where they coordinate of the left sidebearing point is not 0—but very few.) The first point in the defining path is measured relative to the left sidebearing point; subsequent path coordinates are measured relative to the preceding path coordinate."

Although it always talks about the leftmost point, this is only the point where the glyph path starts and finishes, and has no relevance to the direction of the text.

The width vector is used to re-position the current point after a glyph is rendered, the spec says (again under Character Geography):

"A character’s width is a vector, generally horizontal to the right, from the origin to the coordinate at which the current point will be set after showing this character."

Distiller's output of the test file matches the expected output because it moves the current point as directed after rendering the glyphs. As does Ghostscript using its internal rendering engine also the Jaws and Harlequin rips (I don't have a genuine CPSI here to try but I'm confident it will match).

When using FreeType, however, Ghostscript cannot retrieve the correct width vector; the x component is correctly available in the horizontal advance field, the vertical component is not the value returned in the vertical advance field.

So, given that I need to match the behaviour described in the spec, I need access to that 'wy' value, and that's what I'm asking for. Since the horizontal advance returns the 'wx' value it seemed sensible to me that the vertical advance should return the 'wy' value. But if there's a reason to do it a different way, then fine, lets do that.

Kenneth Sharp <kens>
Project Member
Mon 01 Feb 2010 02:05:33 PM UTC, comment #31:

Although Adobe Type1 font spec tells "sbw" operator can use
2D vectors for LeftSideBearing and GlyphWidth, it is difficult
(for me, at least) to understand how to compute LSB and GW
for horizontal & vertical writing mode. The X-coordinate
components are for horizontal writing mode and the Y-coordinate
components are for vertical writing mode? It is unclear (for me,
at least). Thus I think Werner's question is reasonable.

At present, the request looks like "GS expects that FT2 returns
some values fitting to existing algorithm in GS, instead of
synthesized vertical metrics that don't fit to existing algorithm
in GS".

Checking the result of Adobe Distiller's result (I attached), the
result by the combination of existing algorithm in GS and proposed
change of FT2 won't be inconsequent, but it is not sufficient to
determine what values FT2 should return.The clarification how
to use the vectors given by "sbw" is needed. GS maintainers
have any infomation obtained from genuine Adobe implementation,
or Adobe stuffs? If not, I will write to...

(file #19596)

suzuki toshiya <mpsuzuki>
Project Administrator
Mon 01 Feb 2010 01:45:27 PM UTC, comment #30:

Oops, I'm sorry for posting wrong patch including unbuildable
modification for CFF driver. Here is better one.

(file #19595)

suzuki toshiya <mpsuzuki>
Project Administrator
Mon 01 Feb 2010 11:25:55 AM UTC, comment #29:

Toshiya, when I try to apply your patch to FT under Windows I get build errors:

c:\gs-freetype\freetype\src\cff\cffobjs.c(420) : error C2039: 'disable_synthetic_vertical_metric' : is not a member of 'TT_FaceRec_'
c:\gs-freetype\freetype\include\freetype/internal/tttypes.h(1259) : see declaration of 'TT_FaceRec_'

This appears to be because you've modified the CFF_FontRec structure in cfftypes.h to include the flag, but the code in cffobjs.c is using a CFF_Face, which is typedef'ed (in cffobjs.h) to be a TT_FacReec.

Because I don't need the CFF changes for now I've backed out the change to cffobjs.c and the code compiles now.

Together with the GS patch this seems to work well for me and the vertical advance seems to be correct.

Kenneth Sharp <kens>
Project Member
Mon 01 Feb 2010 10:46:27 AM UTC, comment #28:

In the parameters to the sbw operator.

From the Type 1 font spec:

"sbw sbx sby wx wy sbw (12 7)sets the left sidebearing point to (sbx,sby) and sets the characterwidth vector to (wx,wy) in character space."

So the position of the left side-bearing and the advance width in both x and y is encoded in the parameters to the sbw operator.

There may be other metrics in FreeType, but these are the only ones contained in a type 1 glyph description. (there are other, font level metrics as well).

BTW I forgot that sbw is a 2-byte operator, so using hsbw over sbw saves three bytes per instance.

Kenneth Sharp <kens>
Project Member
Mon 01 Feb 2010 10:32:09 AM UTC, comment #27:

> Type 1 fonts don't exactly store the writing direction, but
> they do encode both the horizontal and vertical metrics for all
> glyphs.


How? Where?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Mon 01 Feb 2010 10:19:39 AM UTC, comment #26:

The parameters of sbw belong to both the horizontal and vertical writing directions. Its entirely legal to define all glyphs with sbw, even the horizontal ones, the 'hsbw' is just there to allow horizontal glyphs to be defined more compactly. This is because sbw takes 4 arguments and hsbw only takes 2 so using an sbw for a glyph with 0 vertical advance saves 2 bytes.

You can regard 'hsbw' as simply an 'sbw' with implicit 0 for the vertical advance and y component of the side-bearing.

Type 1 fonts don't exactly store the writing direction, but they do encode both the horizontal and vertical metrics for all glyphs. So in a sense they do encode the 'expected' writing direction, as the glyphs will normally have either a horizontal or vertical advance.

That doesn't mean it isn't possible to write vertically with a font full of horizontal glyphs, or vice versa, but the application has to do all the work by positioning each glyph individually.

As I said, I can see that its useful for an application to know the size of the bitmap, and potentially use that for text positioning when using glyphs in an 'unusual' fashion, eg vertical writing with horizontal glyphs, but the metrics information encoded in the glyph description is vital, even if its 0....

Kenneth Sharp <kens>
Project Member
Mon 01 Feb 2010 10:03:44 AM UTC, comment #25:

I think the main question is whether the parameters of `sbw' belong to the horizontal or vertical direction. IMHO, it's only the former and never the latter. AFAIK, Type 1 fonts don't store the (main) writing direction, right?

A logical consequence is that we should never synthesize the vertical component of the advance value for the horizontal writing direction (so Toshiya-san's patch is not the right one, I believe). A fix should rather remove the calls to ft_synthesize_vertical_metrics if FT_LOAD_VERTICAL_LAYOUT isn't set.

Am I missing something?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Mon 01 Feb 2010 08:35:11 AM UTC, comment #24:

Toshiya, the bug file exhibits a number of problems, many of which are Gs problems, not FreeTtype. However, on pages 4 & 5 of the output you posted you can see that the 'vertical advance' being applied to the glyphs is too large, and this is the part of the problem I need to address now.

(Note that previously this was always 0, but that was addressed separately somewhere)

As you rightly say I need the vertical advance which is contained in the glyph description, via the 'sbw' operator, in order to correctly position the glyphs when printing. Replacing that value with a synthesized metric is I'm afraid plain wrong for a PostScript interpreter.

Not knowing the history behind the vertical metrics synthesis is why I didn't remove it initially but took what I felt to be a more conservative approach of removing the portion that caused a specific problem. BTW Unless I messed up (which is possible, I'm trying to do several projects at once), the vertical advance returned by FreeType used to be always 0.

Anyway I'm happy with any method that allows me to retrieve the correct vertical advance value from the glyph description. This patch seems like a lot of effort but if you think its the best solution then That's fine with me.

I'll try and apply both Toshiya's patches today and verify that they resolve my problem.

Kenneth Sharp <kens>
Project Member
Sun 31 Jan 2010 12:31:27 PM UTC, comment #23:

Werner,

I think what Ken want to do is disabling the vertical
metrics synthesizer, to keep the values defined by
"sbw" operator of PS font.

When gs-cjk members were working to fix vertical
writing mode of GS in 10 years ago, I cannot find
free (or cheap) PostScript fonts including per-glyph
vertical metric defined by "sbw" operator. All I could
find were per-glyph horizontal metric defined by "hsbw".
I think it was the motivation of Chia-I Wu why he
wrote the vertical metrics synthesizer. So I think
the complete removal of vertical metrics synthesizer
can be dangerous for the environment that users
have to render vertical text without "sbw" vertical
metric.

Unfortunately, yet I could not evaluate how many
people writing applications that depends on the
metric synthesized by ft_synthesize_vertical_metrics().
So I tried to disable vertical metrics synthesizer
by optional parameters, aslike "preferred family name"
issue.

Attached is an outline patch to disable/enable
ft_synthesize_vertical_metrics() by FT_Open_Face()
parameters. This is a patch for the source tree
that Ken's 2nd patch set is applied, not for GIT HEAD.

Also I attached another patch for GS to disable
ft_synthesize_vertical_metrics() by this switch.
The results are same with the results by FT2
with Ken's 2nd patch set.

(file #19582, file #19583, file #19584)

suzuki toshiya <mpsuzuki>
Project Administrator
Sat 30 Jan 2010 11:57:34 PM UTC, comment #22:

Here it is.
Ken, the native Type1 vertical advance (what you want to
preserve) is the property set by the operator "sbw"?

(file #19578, file #19579)

suzuki toshiya <mpsuzuki>
Project Administrator
Sat 30 Jan 2010 11:23:22 PM UTC, comment #21:

I'm sorry, previous was different problem.
Soon I will attach another comparison.

suzuki toshiya <mpsuzuki>
Project Administrator
Sat 30 Jan 2010 07:14:26 PM UTC, comment #20:

Ken,

Just I've built GS in SVN HEAD, and compared
the rasterization results of simple "hello world"
between GS own Type1 rasterizer (hello-gsown.png)
versus FAPI FreeType2 plugin (hello-ft2tt.png).
The result by FAPI FT2 shows the problem you're
working for?

# I'm working on Debian GNU/Linux squeeze/sid,
# system freetype version is 2.3.7.

(file #19576, file #19577)

suzuki toshiya <mpsuzuki>
Project Administrator
Sat 30 Jan 2010 09:38:38 AM UTC, comment #19:

Werner I think we're talking at cross-purposes, at least as far as the type 1 font interpreter goes.

The type 1 interpreter can only return the information in the glyph program. This cannot know anything about the intended use of the glyph. However, the metrics are always present in a type 1 glyph, either explicitly or implicitly.

Either a glyph will use the hsbw operator which explicitly sets the horizontal metrics to the supplied values and implicitly sets the vertical metrics to 0, OR the glyph may use the sbw operator which explicitly sets both the horizontal and vertical metrics.

In this case the available metrics are the horizontal and vertical advance, and the x/y co=ordinate of the side bearing. Note that there is only one side-bearing in a PostScript glyph, the hsbw operator sets its x co-ordinate only (y is implicitly 0) the sbw operator sets both the x and y values.

So as I said it seems to me that by using the information from the type 1 interpreter there is no need to synthesize the vertical metrics.

What I'm unsure about is whether there are additional vertical (and horizontal for that matter) metrics beyond the side bearing and advance which might require to be generated.

I can see that the dimensions of the glyph might be useful information to a calling application, but these should not be confused with the advance values from the glyph program.

If FT returns a calculated vertical advance based on the glyph size it is actually corrupting the information which is required by a PostScript interpreter. The PS interpreter must know the horizontal and vertical advance values from the type 1 font program, these are vital pieces of information.

BTW this isn't related to the incremental interface, this problem is the same for the regular method of using FreeType, the vertical advance value returned in the metrics for a type 1 glyph is not the vertical advance value which is set in the type 1 glyph program.

Kenneth Sharp <kens>
Project Member
Sat 30 Jan 2010 05:50:15 AM UTC, comment #18:

> Yes, but this doesn't matter to a type 1 font/PostScript
> interpreter. As the font interpreter follows the glyph
> program it doesn't need to know whether its intended for
> vertical or horizontal reading, the current point is simply
> advanced (by the PS interpreter) after drawing a glyph, by
> the specified horizontal and vertical advance for that
> glyph.


Well, here is obviously a difference between FreeType and a PS interpreter. We always try to return both a rendered glyph image together with useful metrics and advance values. The user selects the writing direction and should get some expected results, either native or synthesized.

What I need is a fix which goes beyond the needs of GhostScript, namely a generic solution as outlined in the previous paragraph. It's OK with me if we currently restrict the incremental interface to do less than it should do, however, this only can be an intermediate solution IMHO. It's also OK with me if there is no real `improvement' in 2.3.12 but just bug fixes so that GhostScript can work with this version, but again, I would like to have a `right' solution.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 29 Jan 2010 01:55:33 PM UTC, comment #17:

>metrics only if the user has specified FT_LOAD_VERTICAL_LAYOUT,
>and the font doesn't provide native vertical metrics. This load
>flag is marked as `problematic' currently, so we are more or
>less free to find a satisfying, possibly incompatible solution.


Umm, well type 1 fonts in essence always contain both horizontal and vertical metrics. For a horizontal font the vertical advance will be 0, and the side-bearing will normally nave no y-component.

>I think that you are talking about something different, namely
>that there are both vertical and horizontal advance values for
>horizontal typesetting. Is this correct?


Well sort of, but see below. Possibly we are using the word 'metrics' for somewhat different purposes.

>As far as I can see, while parsing a Type 1 file, it isn't
>possible at all to find out whether the font is intended for
>vertical typesetting or not – only the corresponding AFM file
>can contain vertical metrics.


Yes, but this doesn't matter to a type 1 font/PostScript interpreter. As the font interpreter follows the glyph program it doesn't need to know whether its intended for vertical or horizontal reading, the current point is simply advanced (by the PS interpreter) after drawing a glyph, by the specified horizontal and vertical advance for that glyph.

For this reason a PostScript rip never uses an AFM file, AFM files are for applications so that they can 'properly' position glyphs. That is, the application can tell where the current point will be after a glyph is shown and can adjust it if required. Obvious examples are line breaks, super/subscript, H&J, kerning, etc.

So PostScript itself has no real concept of horzintal or vertical reading, it simply draws a glyph, advances by x and y and then draws the next glyph. For a 'normal' horizontal font y will be 0 and for a vertical font x will be 0.

Applications can read the AFM file to determine how much to advance the x or y value after line breaks, or can use the FontBBox.

I don't think that there is a need for more fields as such. PostScript glyphs have both a vertical and horizontal advance, but usually one of these is 0. You can't use the same glyphs in PostScript for both horizontal and vertical writing (well you can, but you have to position the glyphs individually). So there is no need to have both horizontal and vertical advance values for rendering in each direction, you can only render in one 'direction' in PostScript.

Sort of summary
----------------
The first problem (earlier patch) was that the vertical advance value parsed out of the glyph wasn't being passed on, but was always set to 0. This is a problem for any glyph which has a non-zero vertical advance of course.

The second problem was limited to the incremental interface, and revolved around the fact that we only called get_glyph_metrics for the horizontal metrics, so there was no opportunity to override the vertical metrics. This is pretty minor actually, but nice to do.

Both of these have been resolved. The problem now is that the Type 1 interpreter calls synthesize_vertical_metrics unconditionally. Now if we have a zero vertical advance this overwrites it with a heuristic value (we can worry about the load flags separately ;-)

When we were always setting the vertical advance to 0 this wasn't a problem, because we overwrote the heuristic value with 0 again, so the vast majority of fonts simply work. (NB PostScript jobs containing vertically written glyph in type 1 format pretty much always position glyphs individually, so this is not normally an issue, which is why this probably hasn't ever come up).

Since we've fixed the clamping to 0, the heuristic value is an issue, because glyphs which should have no vertical advance now gain one (glyph height * 1.2).

From what you've said I think the right thing to do is not to call synthesize_vertical_metrics from the type 1 or CFF interpreters. These interpreters already gather any vertical metric data and (now) make it available to the calling application via the get_glyph_metrics callback. I believe this is also true of the CIDFont interpreter as well.

>The whole code is messy, I know. Sorry for that. It would be
>really great if you can improve this!


You haven't seen the awful mess of the Ghostscript interface to FreeType :-(

This code is much better than that.....

Kenneth Sharp <kens>
Project Member
Fri 29 Jan 2010 01:10:46 PM UTC, comment #16:

First of all a clarification. FreeType should synthesize vertical metrics only if the user has specified FT_LOAD_VERTICAL_LAYOUT, and the font doesn't provide native vertical metrics. This load flag is marked as `problematic' currently, so we are more or less free to find a satisfying, possibly incompatible solution.

I think that you are talking about something different, namely that there are both vertical and horizontal advance values for horizontal typesetting. Is this correct?

As far as I can see, while parsing a Type 1 file, it isn't possible at all to find out whether the font is intended for vertical typesetting or not – only the corresponding AFM file can contain vertical metrics. Currently, FreeType completely ignores any metrics info from an AFM file, which is OK for horizontal data but bad for vertical typesetting. In other words, if the user requests vertical typesetting, FreeType should currently synthesize vertical metrics information until the AFM parser has been extended to read in the corresponding data (and the AFM file gets attached to the font).

It seems that I've made a mistake: Apparently we need an additional field to hold the vertical component of the advance value for the horizontal writing direction (note the complicated wording to exactly describe the situation). Similarly, we need these two fields for the vertical writing direction too.

The whole code is messy, I know. Sorry for that. It would be really great if you can improve this!

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 29 Jan 2010 09:18:18 AM UTC, comment #15:

Hi Werner, yes the type 1 interpreter does properly return real metrics, horizontal and (if present) vertical. Which is why the problem arises, the synthesised vertical metrics overwrite the '0' for a horizontal glyph (my test font contains both horizontal, vertical and 'mixed' glyphs which advance in both directions). I need FT to return the vertical metrics when they are present, but I also need the 0 to remain at 0 when there is no vertical advance.

Possibly the type 1 interpreter shouldn't be calling the routine to synthesize the vertical metrics, that would make sense, but...

The routine is unconditionally called from the type 1 interpreter in t1gload.c, T1_Load_Glyph. It seemed to me that creating a vertical advance when it was 0 was more wrong than synthesising the other metrics, but I'm not an expert on the internals of FT. Because all the interpreters bar TrueType call the routine I thought it best not to remove the call.

Given what you say, it seems likely this function should simply not be called from the type 1 (or CFF) font interpreters. Glyphs in these fonts should always set the required metrics, and metrics which are not specifically set should be left at 0.

So given that, do you think it better to remove the call to synthesize_vertical_metrics altogether ? I think it likely that some of the vertical metrics entries are not currently being filled in (even though the data is implicitly available) so that would need to take the place of the function call.

I would need to do the same for the CFF interpreter. It seems likely the same fix would be required for the CID interpreter, but we don't use that (we handle CIDFonts by passing the descendants to FreeType). It seems FreeType only supports CIDFonts with type 1 descendants at present.

Let me know what you think please, I have time to continue working on this at present, as I'm also chasing bugs in the GS implementation of FT.

NOTE! as far as I can see no font format interpreter 'tests' for the existence of these metrics, they either create them unconditionally (bdfdrivr.c, cffgload.c, cidgload.c, pcfdrivr.c, t1gload.c and winfnt.c) or never call the routine at all (TrueType)

I don't have a 'real world' font that has vertical metrics, I have a hand-constructed (but legal) PostScript file containing fonts built in various interesting ways intended to expose bugs so I can fix them. You are welcome to a copy of it but I'm doubtful it would be helpful, the font is constructed using PostScript dictionaries and needs a PostScript interpreter rather than being a disk based PFB font or anything like that. It does render correctly (ie as expected) on various PostScript RIPs I have here.

I might be able to do something by converting it to PDF using Acrobat Distiller, I think that would produce a CFF version of the font. Its not quite the same as the type 1 I've been using but I think the same problems would apply as the same unconditional call to synthesize_vertical_metrics is made in cffgload.c. Let me know if you'd like me to try that, I'd be happy to pull the font out of the PDF file afterwards.

Kenneth Sharp <kens>
Project Member
Thu 28 Jan 2010 06:52:58 PM UTC, comment #14:

Thanks. However, this can't be the right patch! It's part of the `ft_synthesize_vertical_metrics' function, and as its name says, it should be used to synthesize vertical metrics if real ones aren't available. In your case, you actually have real vertical metric values, haven't you?

We thus need some logic to find out whether this function must be called or not.

Do you time to work on this? Regardless of this, can you post a font with real vertical metrics (or send it to me privately in case this isn't possible for legal reasons)?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 28 Jan 2010 04:31:24 PM UTC, comment #13:

I obviously need my winter vacation.....

Hopefully its attached this time.

(file #19560)

Kenneth Sharp <kens>
Project Member
Thu 28 Jan 2010 04:19:38 PM UTC, comment #12:

The attachment is missing...

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Wed 27 Jan 2010 03:07:58 PM UTC, comment #11:

Sorry Werner, I missed an important line of change in the patch. I've attached it as ftobjs.diff.

In the routine ft_synthesize_vertical_metrics, if the vertical advance is 0 it is replaced here with a heuristic 'invented' value based on the glyph height. We really need this to be the correct value of 0, which we interpreted in the type 1 interpreter. This would also be true for the CFF interpreter

I don't know what implications this might have for other font formats, as these all seem to use the same routine.

Kenneth Sharp <kens>
Project Member
Wed 27 Jan 2010 02:38:39 PM UTC, comment #10:

Spoke too soon, there is something 'odd' happening, it sort of looks like the vertical advance is being added twice. I'm not sure why yet, its probably my code.

Just a 'heads up'.

Kenneth Sharp <kens>
Project Member
Wed 27 Jan 2010 02:14:24 PM UTC, comment #9:

Inspection and some quick testing, that seems to work just great Werner, thanks very much !

Kenneth Sharp <kens>
Project Member
Wed 27 Jan 2010 09:18:28 AM UTC, comment #8:

<sigh> You're quite right Werner, I'm afraid I was having trouble with VMWare and I ended up copying blocks of code around, I rather obviously messed up there. Thanks for correcting that.

I'll grab new sources as soon as possible, I'm disappearing under a mound of other stuff today so it might not be till tomorrow.

I know you want to get a release together soon so I'll try and do it today if I can.

Kenneth Sharp <kens>
Project Member
Wed 27 Jan 2010 09:06:16 AM UTC, comment #7:

Hmm. In cffgload.diff and cidgload.c, you certainly want to use TRUE within the if-blocks, right? Otherwise you load horizontal metrics twice...

I've changed that accordingly and pushed it. Please test and check.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Mon 25 Jan 2010 09:48:59 AM UTC, comment #6:

OK, attached three diff files, one each for cffgload.c, cidgload.c and t1gload.c.

All three call the get_glyph_metrics callback twice, once for horizontal and once for vertical. This allows the opportunity to override the metrics with the incremental interface.

t1gload.c additionally removes a couple of lines of code which calculate a vertical advance based on the glyph bounding box, and instead use the vertical advance interpreted from the glyph program.

I notice that the code in ttgload.c which calls get_glyph_metrics for the vertical metrics has been #if'ed out. I haven't altered that; so far its not causing us a problem, and I presume there's a good reason for removing it.

(file #19544, file #19545, file #19546)

Kenneth Sharp <kens>
Project Member
Sat 23 Jan 2010 04:40:16 PM UTC, comment #5:

Yes, please prepare a new patch. Thanks in advance!

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Sat 23 Jan 2010 04:05:59 PM UTC, comment #4:

Werner, I see your point, you are quite correct. There is no need to add a vertical advance, since you can achieve this by 2 calls to set the vertical and horizontal advances separately.

In this case the first part of the patch should be revised to simply add a second call to get_glyph_metrics to retrieve the vertical advance. This needs to be done for both the type 1 and CFF interpreters.

I see that Ghostscript doesn't deal properly with the third parameter either, and always assumes the advance is horizontal, so I'll fix that.

Do you want me to prepare a revised patch ? I won't be able to do that until Monday.

Kenneth Sharp <kens>
Project Member
Sat 23 Jan 2010 03:59:59 PM UTC, comment #3:

I believe you. There are problems in the code. However, I just wonder whether we can avoid extending a structure in a public header file...

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Sat 23 Jan 2010 03:50:30 PM UTC, comment #2:

Werner I'll check this ASAP but I think that the vertical advance defined by the Type 1 'sbw' instruction is definitely being overwritten.

Kenneth Sharp <kens>
Project Member
Sat 23 Jan 2010 12:49:13 PM UTC, comment #1:

I'm not sure whether the patch is the right one. I believe that you can avoid the introduction of a new `vert_advance' field: The `get_glyph_metrics' callback's third argument specifies whether you are asking for horizontal or vertical metrics. Basically, you should call this function a second time to retrieve the data you need (as is done e.g. in the TrueType driver, possibly incomplete for your purposes).

Can you check this, please?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Mon 18 Jan 2010 04:28:02 PM UTC, original submission:

A Type 1 font may have a vertical as well as a horizontal advance. There are two issues with the vertical advance with FreeType.

1) The incremental interface offers an opportunity to override the font metrics, and in particular the horizontal advance, but makes no provision for overriding the vertical advance. cf the incremental interface 'get_glyph_metrics' callback.

2a) If the incremental interface is used, after calling the get_glyph_metrics callback the vertical advance is unconditionally set to 0.

2b) Even if the incremental interface is not used, the vertical advance in the glyph description is overwritten by a 'synthesized' vertical advance in two places, the type 1 font interpreter (always) and also in ft_synthesize_vertical_metrics, if the vertical advance happens to be 0 (which it usually is except that the type 1 interpreter has already written a non-zero value).

The attached patch modifies the 'FT_Incremental_MetricsRec' structure to add a new filed for the vertical advance 'vert_advance'. This field is set from the interpreted vertical advance in the CFF, CID, Type 1 and TrueType interpreters (fixed at 0 in TrueType). The structure is then sent to the get_glyph_metrics callback and on return the value of vert_advance is used to set the value from the interpreter.

Changes to ft_increm.h, cffgload.c, cidgload.c, t1gload.c, ttgload.c.

t1gload.c is then further modified so that it uses the value of vertical advance from the font interpreter rather than inventing a new value based on the glyph bounding box.

Finally in ftobjs.c, ft_synthesize_vertical_metrics, if the vertical advance happens to be 0 we do not replace it with a synthesized value (but we still calculate that value for other purposes).

Kenneth Sharp <kens>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #19619:  metrics.zip added by kens (3KiB - application/x-zip-compressed)
file #19618:  bug689267_mps-2Dadv.tar.lzma added by mpsuzuki (47KiB - application/octet-stream)
file #19596:  bug689267.pdf added by mpsuzuki (40KiB - application/pdf)
file #19584:  bug689267_mps-refix.tar.lzma added by mpsuzuki (70KiB - application/octet-stream)
file #19578:  bug689267_before-kenfix.tar.lzma added by mpsuzuki (59KiB - application/octet-stream)
file #19579:  bug689267_after-kenfix.tar.lzma added by mpsuzuki (70KiB - application/octet-stream)
file #19576:  hello-gsown.png added by mpsuzuki (1KiB - image/png)
file #19577:  hello-ft2tt.png added by mpsuzuki (1KiB - image/png)
file #19560:  ftobjs.diff added by kens (525B - application/octet-stream)
file #19544:  cffgload.diff added by kens (1KiB - application/octet-stream)
file #19545:  t1gload.diff added by kens (2KiB - application/octet-stream)
file #19546:  cidgload.diff added by kens (1KiB - application/octet-stream)
file #19516:  ft-patch-2010-01-18.diff added by kens (5KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by chrisl
  • -unavailable- added by mpsuzuki (Updated the item)
  • -unavailable- added by kens (Posted a comment)
  • -unavailable- added by kens
  • -unavailable- added by wl (Posted a comment)
  • -unavailable- added by kens
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 25 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 10 Feb 2010 06:16:09 AM UTCwlStatusNeed Info=>Fixed
      Open/ClosedOpen=>Closed
    Thu 04 Feb 2010 03:18:31 PM UTCkensAttached File-=>Added metrics.zip, #19619
    Thu 04 Feb 2010 01:04:10 PM UTCmpsuzukiAttached File-=>Added ft2-extend-advance-2D.patch, #19616
      Attached File-=>Added gs-use-extended-2D-advance-in-ft.patch, #19617
      Attached File-=>Added bug689267_mps-2Dadv.tar.lzma, #19618
    Thu 04 Feb 2010 11:12:09 AM UTCchrislCarbon-Copy-=>Added -unavailable-
    Tue 02 Feb 2010 01:52:41 PM UTCmpsuzukiAttached File-=>Added add-ft-get-ps-sbw-params.patch, #19607
    Mon 01 Feb 2010 02:05:33 PM UTCmpsuzukiAttached File-=>Added bug689267.pdf, #19596
    Mon 01 Feb 2010 01:45:27 PM UTCmpsuzukiAttached File-=>Added add-switch-to-disable-ft-synthesize-vertical-metric_20100201.patch, #19595
    Sun 31 Jan 2010 12:31:27 PM UTCmpsuzukiAttached File-=>Added add-switch-to-disable-ft-synthesize-vertical-metric.patch, #19582
      Attached File-=>Added gs-svn_disable-ft-synthetic-vertical-metric.patch, #19583
      Attached File-=>Added bug689267_mps-refix.tar.lzma, #19584
    Sat 30 Jan 2010 11:57:34 PM UTCmpsuzukiAttached File-=>Added bug689267_before-kenfix.tar.lzma, #19578
      Attached File-=>Added bug689267_after-kenfix.tar.lzma, #19579
    Sat 30 Jan 2010 07:14:26 PM UTCmpsuzukiAttached File-=>Added hello-gsown.png, #19576
      Attached File-=>Added hello-ft2tt.png, #19577
    Thu 28 Jan 2010 06:52:58 PM UTCwlOpen/ClosedClosed=>Open
    Thu 28 Jan 2010 04:31:24 PM UTCkensAttached File-=>Added ftobjs.diff, #19560
    Thu 28 Jan 2010 04:19:38 PM UTCwlStatusFixed=>Need Info
    Wed 27 Jan 2010 09:06:16 AM UTCwlStatusNeed Info=>Fixed
      Open/ClosedOpen=>Closed
      Planned ReleaseNone=>2.3.12
    Mon 25 Jan 2010 09:48:59 AM UTCkensAttached File-=>Added cffgload.diff, #19544
      Attached File-=>Added t1gload.diff, #19545

    Back to the top


    Powered by Savane 3.1-cleanup1