bugGNU roff - Bugs: bug #52865, [libdriver] abandon...

 
 

bug #52865: [libdriver] abandon STUPID_DRAWING_POSITIONING

Submitter:  None
Submitted:  Thu 11 Jan 2018 07:49:50 PM UTC
   
 
Category:  Driver - others/general Severity:  1 - Wish
Item Group:  Feature change Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 07 Oct 2022 12:57:45 AM UTC, comment #4: 

I tend to concur with the submitter; our current and purportedly backward compatible handling of these drawing commands seems quite startling and bizarre.

Furthermore, DWB 3.3 troff is available in a form buildable and usable on modern systems, so we can always check behavior against old-school troff, not simply ancient versions of groff that no one uses anymore.

Expanding scope.  Let's kill STUPID_DRAWING_POSITIONING and do what is conceptually correct, maybe for groff 1.24.

G. Branden Robinson <gbranden>
Group administrator
Fri 12 Jan 2018 01:55:47 PM UTC, comment #3: 

I thought looking at parse_D_command() unveils the obvious.
But, to continue the discussion:, what prevented disabling of STUPID_DRAWING_POSITIONING after it has been introduced a few weeks before those bugs sprang into existence (in [ea5a42d0] anything is alright still)?

Anonymous
Fri 12 Jan 2018 12:03:24 AM UTC, comment #2: 

This appears to be similar to the command Dt where the line thickness parameter is actual treated as a horizontal movement as well. This behaviour is documented for Dt in the groff_out man page, but not for Df.

The attached troff file illustrates the position. The relevent troff output is:-


s20000
V96000
H72000
mg 31000
DFd
tDeri
wh5000
tJames
n24000 0
V144000
H72000     <---
Df 31000 0
DC 72000 0
H103000    <---
md
tDeri
wh5000
tJames
n24000 0


Note that the the horizontal position is first set to 72000 then after the Df 31000 the horizontal position is set to 103000. It should also be noted that grops "knows" about this side effect, but gropdf does not. The two devices position the filled circle differently, but once the H103000 repositions the horizontal they operate the same.

(file #42888)

Deri James <deri>
Group Member
Thu 11 Jan 2018 09:29:19 PM UTC, comment #1: 

Please provide a small sample to make the issue easier to comprehend.

Werner LEMBERG <wl>
Group administrator
Thu 11 Jan 2018 07:49:50 PM UTC, original submission:  

Hey, it is me :).
Yeah.  Since then it skips a non-existing integer and applies horizontal movement with a value that represents gray colour.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #42888:  gray.trf added by deri (107B - application/octet-stream - Illustrates Df horizontal movement)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by deri (Updated the item)
  • -email is unavailable- added by wl (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-07 gbranden Severity3 - Normal 1 - Wish
        Item GroupIncorrect behaviour Feature change
        StatusNeed Info Confirmed
        Summarylib-driver, input: Df broken (since 2002) [libdriver] abandon STUPID_DRAWING_POSITIONING
    2022-01-11 gbranden CategoryNone Driver - others/general
        Item GroupNone Incorrect behaviour
    2018-01-12 deri Attached File- Added gray.trf, #42888
    2018-01-11 wl StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code