Victor Mote wrote (on Monday):
> The following methods have now been added to org.axsl.font.Font:
> public byte nextBolderWeight() ;
> public byte nextLighterWeight() ;
> public Font nextBolderFont() ;
> public Font nextLighterFont() ;
>
> public int unavailableChar(String str
Victor Mote a écrit :
The following methods have now been added to org.axsl.font.Font:
public byte nextBolderWeight() ;
public byte nextLighterWeight() ;
public Font nextBolderFont() ;
public Font nextLighterFont() ;
public int unavailableChar(String string, int beginIndex) ;
Victor Mote wrote (August 27, 2005):
> > > In order to move forward, I suggest the addition of the following
> > > methods in
> > > org.axsl.font.Font:
> > >
> > > public byte nextBolderWeight();
> > > public byte nextLighterWeight();
> > > public org.axsl.font.Font nextBolderFont();
Victor Mote a écrit :
As I understand the spec, this works differently from
font-weight and can be resolved in the FO Tree: just select
the next expanded value for "wider" or next condensed for
"narrower". The font selection would be performed only after,
when it is time to decide e.g. which f
Manuel Mall wrote:
> I am with Vincent on this one. Here is the text for "wider"
> from the spec ("smaller" is defined the same way):
> The relative keyword "wider" sets the value to the next
> expanded value above the inherited value (while not
> increasing it above "ultra-expanded").
>
> No
Vincent Hennebert wrote:
> Victor Mote a écrit :
> > I am ignoring font-stretch for now. I am unclear whether it works
> > similarly to font-weight, or whether it is totally
> resolvable in the FO Tree.
> > Interestingly, CSS 2.1 (the only version of CSS 2 still
> available at
> > W3C) removes
On Fri, 26 Aug 2005 10:35 pm, Vincent Hennebert wrote:
> Victor Mote a écrit :
> > I am ignoring font-stretch for now. I am unclear whether it works
> > similarly to font-weight, or whether it is totally resolvable in
> > the FO Tree. Interestingly, CSS 2.1 (the only version of CSS 2
> > still avai
Victor Mote a écrit :
I am ignoring font-stretch for now. I am unclear whether it works similarly
to font-weight, or whether it is totally resolvable in the FO Tree.
Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C)
removes font-stretch entirely!!??!!
As I understand the
On 26.08.2005 15:00:46 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > I believe that font-stretch has to included just like
> > font-weight to select the actual font.
>
> Sorry to be unclear. I understand that font-stretch must be included. The
> issue is whether the "wider" and "narrower" c
Jeremias Maerki wrote:
> I believe that font-stretch has to included just like
> font-weight to select the actual font.
Sorry to be unclear. I understand that font-stretch must be included. The
issue is whether the "wider" and "narrower" constraints can be processed in
the FOTree by simply bumpi
On 25.08.2005 18:10:51 Victor Mote wrote:
> Victor Mote wrote (August 8):
>
> > Manuel Mall wrote:
> >
> > > Regarding the "bolder", "lighter" issue and the general
> > font selection
> > > I looked at the "pre-patch for FOrayFont adaptation to Fop"
> > > (http://issues.apache.org/bugzilla/sho
Victor Mote wrote (August 8):
> Manuel Mall wrote:
>
> > Regarding the "bolder", "lighter" issue and the general
> font selection
> > I looked at the "pre-patch for FOrayFont adaptation to Fop"
> > (http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and
> > concluded that meddling with t
Victor Mote a écrit :
Manuel Mall wrote:
Regarding the "bolder", "lighter" issue and the general font
selection I looked at the "pre-patch for FOrayFont adaptation
to Fop"
(http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and
concluded that meddling with the font selection system wi
Manuel Mall wrote:
> Regarding the "bolder", "lighter" issue and the general font
> selection I looked at the "pre-patch for FOrayFont adaptation
> to Fop"
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and
> concluded that meddling with the font selection system will
> interfere
On 08.08.2005 06:16:58 Manuel Mall wrote:
> On Mon, 8 Aug 2005 01:04 am, Jeremias Maerki wrote:
>
> >
> > Another important area would be URI resolution and proper and
> > consistent resolution of relative paths. I think that is something
> > that bugs especially our users through Cocoon. There a
On Mon, 8 Aug 2005 01:04 am, Jeremias Maerki wrote:
>
> Another important area would be URI resolution and proper and
> consistent resolution of relative paths. I think that is something
> that bugs especially our users through Cocoon. There are a few
> (older) notes about that in the Wiki. In thi
Jeremias,
fair enough. I have done the "larger", "smaller" bits as they are
constrained to the fop property subsystem and will post a patch later.
They were quite a handy starting point in trying to understand the fop
property system.
Regarding the "bolder", "lighter" issue and the general f
Sounds like a few changes are necessary. Frankly, "larger", "smaller",
"bolder" and "lighter" are really not that important right now. I can't
remember anyone ever asking for them (although I could have simply not paid
attention). Yes, I think this could interfere with the FOray font
integration wo
I was looking at how to implement support for relative font weights
("bolder" and "lighter"). The spec says that a relative font weight
refers to the next lighter or bolder font. This means we cannot simply
subtract/add 100 to the weight but we have to find the next font
relative to the current
19 matches
Mail list logo
