My favorites | Sign in
Project Logo
             
Details: Show all Hide all

Earlier this year

  • Oct 25, 2009
    r309 (Added modify() method for treatments, so PerChevron and PerP...) committed by m...@kli.org   -   Added modify() method for treatments, so PerChevron and PerPall can be inverted
    Added modify() method for treatments, so PerChevron and PerPall can be inverted
  • Jan 18, 2009
    BlazonIntro (Introduction to Blazonry the pyBlazon way) Wiki page edited by m...@kli.org
  • Jan 12, 2009
    r307 (Change to allow tinctures of the form '#ffffff'. Also fix to...) committed by m...@kli.org   -   Change to allow tinctures of the form '#ffffff'. Also fix to error func of lexer because plylex wanted it.
    Change to allow tinctures of the form '#ffffff'. Also fix to error func of lexer because plylex wanted it.

Older

  • Oct 14, 2008
    issue 29 (Collision detection/introspection) reported by a...@nvg.org   -   We need to be able to know where we are drawing stuff, instead of relying on fire-and-forget. This would be tremendously helpful in order to be able to both avoid undue overlapping, and fill the areas properly, without resorting to manual tweaking and ad-hockery.
    We need to be able to know where we are drawing stuff, instead of relying on fire-and-forget. This would be tremendously helpful in order to be able to both avoid undue overlapping, and fill the areas properly, without resorting to manual tweaking and ad-hockery.
  • Oct 13, 2008
    issue 28 (Inkscape compatibility) reported by a...@nvg.org   -   Currently, the SVG produced by pyBlazon is rather messy and difficult to work with in post-processing. The SVG should be at least so simple that it displays correctly in Inkscape, and that changing the position of charges is straightforward.
    Currently, the SVG produced by pyBlazon is rather messy and difficult to work with in post-processing. The SVG should be at least so simple that it displays correctly in Inkscape, and that changing the position of charges is straightforward.
  • Oct 13, 2008
    issue 27 (Charges are arranged badly with quarterly) reported by a...@nvg.org   -   What steps will reproduce the problem? 1. Quarterly Or and sable, four annulets countercharged. What is the expected output? What do you see instead? For once, the charges are pretty small (see issue 25), but the annulets in the two base quadrants look rubbish, because they are too close to the edge of the shield. Not sure how this should be done properly, but I think the solution need to satisfy both of the following constraints: a) the annulets in the top and the base should be aligned; b) the annulets in the base should be approximately in the middle of the quadrants.
    What steps will reproduce the problem? 1. Quarterly Or and sable, four annulets countercharged. What is the expected output? What do you see instead? For once, the charges are pretty small (see issue 25), but the annulets in the two base quadrants look rubbish, because they are too close to the edge of the shield. Not sure how this should be done properly, but I think the solution need to satisfy both of the following constraints: a) the annulets in the top and the base should be aligned; b) the annulets in the base should be approximately in the middle of the quadrants.
  • Oct 13, 2008
    issue 26 (External <symbol>s are not displayed in Opera) reported by a...@nvg.org   -   What steps will reproduce the problem? 1. Argent a mullet vert. What is the expected output? What do you see instead? In Opera, a completely blank shield is displayed. This could be a problem with <use> in Opera. Then again, it might be a problem with pyBlazon.
    What steps will reproduce the problem? 1. Argent a mullet vert. What is the expected output? What do you see instead? In Opera, a completely blank shield is displayed. This could be a problem with <use> in Opera. Then again, it might be a problem with pyBlazon.
  • Oct 13, 2008
    issue 25 (Lozenges are too small) reported by a...@nvg.org   -   What steps will reproduce the problem? 1. Or two lozenges vert. What is the expected output? What do you see instead? The lozenges should fill much more of the shield.
    What steps will reproduce the problem? 1. Or two lozenges vert. What is the expected output? What do you see instead? The lozenges should fill much more of the shield.
  • Aug 12, 2008
    issue 24 (Support for modifying pily treatments) Status changed by a...@nvg.org   -   This can be achieved with "barry pily" and "bendy pily". But we should add the alternate way into the grammar
    Status: Accepted
    This can be achieved with "barry pily" and "bendy pily". But we should add the alternate way into the grammar
    Status: Accepted
  • Aug 12, 2008
    issue 23 (Support for "couped") Status changed by a...@nvg.org   -   Confirmed. We can't do "Azure three frets argent" either. This should mostly be a matter of drawing a new graphic.
    Status: Accepted
    Confirmed. We can't do "Azure three frets argent" either. This should mostly be a matter of drawing a new graphic.
    Status: Accepted
  • Aug 09, 2008
    issue 9 (Support compony) commented on by w...@circle-cross.org   -   I believe a bordure can also be compony (and counter-compony, but let's not get too out-of-hand).
    I believe a bordure can also be compony (and counter-compony, but let's not get too out-of-hand).
  • Aug 09, 2008
    issue 24 (Support for modifying pily treatments) reported by w...@circle-cross.org   -   pyblazon currently faults when parsing "pily fesswise sable and argent". The grammar currently lacks the notion of an inversion/direction modification ("optinverted") following "pily" (a "LINEY"). For other "LINEY"s, it's not critical, as each directional modification has a separate "LINEY" expression, but "pily" has no horizontal or diagonal equivalents, requiring "pily fesswise", "pily bendwise", and "pily bendwise sinister" to achieve the correct orientation.
    pyblazon currently faults when parsing "pily fesswise sable and argent". The grammar currently lacks the notion of an inversion/direction modification ("optinverted") following "pily" (a "LINEY"). For other "LINEY"s, it's not critical, as each directional modification has a separate "LINEY" expression, but "pily" has no horizontal or diagonal equivalents, requiring "pily fesswise", "pily bendwise", and "pily bendwise sinister" to achieve the correct orientation.
 
Hosted by Google Code