bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #62934] [gropdf] sometimes \(em becomes a different char when rende


From: G. Branden Robinson
Subject: [bug #62934] [gropdf] sometimes \(em becomes a different char when rendered
Date: Tue, 23 Aug 2022 05:36:38 -0400 (EDT)

Update of bug #62934 (project groff):

                Category:                 General => Device gropdf          
                  Status:          Ready For Test => Fixed                  
             Assigned to:                    None => deri                   
             Open/Closed:                    Open => Closed                 
         Planned Release:                    None => 1.23.0                 
                 Summary: gropdf: sometimes \(em becomes a different char when
rendered with gropdf => [gropdf] sometimes \(em becomes a different char when
rendered

    _______________________________________________________

Follow-up Comment #3:


commit f275b477e0f49d180224a77271c1b68e913b71b5
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Mon Aug 22 23:30:40 2022 +0100

    Bug #62934 - after glyph remapped mark it as used
    
    When many glyphs are remapped from code points above 255
    such as writing documents in cyrillic with the U-TR fonts,
    gropdf starts reusing code points in the range 128-255.
    If subsequently one of those code points is actually required,
    such as \(em (code 138), and it has been replaced by a
    cyrillic, then it needs to be mapped to another free code.
    
    To determine if a particular code point is free each glyph
    has a USED flag. The bug was caused because after remapping
    \(em to the next free glyph the USED flag was not set. So the
    next new cyrillic character to be entered was given the same
    code point as had been allocated to \(em.
    
    * src/devices/gropdf/gropdf.pl: Set the USED flag on remapped
    glyphs.
    
    Fixes <https://savannah.gnu.org/bugs/?62934>.
    
    Thanks to Nikita Ivanov for spotting the problem and testing
    the fix.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62934>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]