[bug #65137] [troff] support construction of arbitrary byte sequences in device control commands

[G. Branden Robinson]

Update of bug#65137 (group groff):

  Status:None => Duplicate  
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Duplicates bug #63074.  Will migrate comment #0 over there.


___

Reply to this item at:

  

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

[bug #65137] [troff] support construction of arbitrary byte sequences in device control commands

[G. Branden Robinson]

Follow-up Comment #1, bug#65137 (group groff):

This isn't a strict dependency, but see bug #64484.


___

Reply to this item at:

  

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

[bug #65137] [troff] support construction of arbitrary byte sequences in device control commands

[G. Branden Robinson]

URL:
  

 Summary: [troff] support construction of arbitrary byte
sequences in device control commands
   Group: GNU roff
   Submitter: gbranden
   Submitted: Mon 08 Jan 2024 10:13:02 AM UTC
Category: Core
Severity: 1 - Wish
  Item Group: Feature change
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None


___

Follow-up Comments:


---
Date: Mon 08 Jan 2024 10:13:02 AM UTC By: G. Branden Robinson 
This is my generalization of Deri's `stringhex` request in the deri-gropdf-ng
branch.

In my working copy, I embedded the idea where the code would go.


diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index a0b987634..f6e5b1279 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -5571,7 +5571,7 @@ static node *do_non_interpreted()
   return new non_interpreted_node(mac);
 }
 
-static void encode_char(macro *mac, char c)
+static void encode_char_for_device_control(macro *mac, char c)
 {
   if (c == '\0') {
 if (tok.is_stretchable_space()
@@ -5600,6 +5600,13 @@ static void encode_char(macro *mac, char c)
   else if (strcmp("ti", sc) == 0)
mac->append('~');
   else {
+   // TODO: Support '\[u]' for all devices to support
+   // transmission of arbitrary data to the output device.  It's a
+   // misnomer--this doesn't necessarily represent a Unicode code
+   // point, but this syntax beats inventing a new one for this
+   // esoteric purpose.  Whether one sends \[uAABB],
+   // \[u00AA]\[u00BB], or the latter's byte-swapped counterpart is
+   // an interface detail that the output device must specify.
if (font::use_charnames_in_special) {
  if (sc[0] != (char)0) {
mac->append('\\');
@@ -5612,9 +5619,14 @@ static void encode_char(macro *mac, char c)
mac->append(']');
  }
  else
- error("special character '%1' cannot be used within"
-   " device control escape sequence", sc);
+   error("special character '%1' cannot be used within a"
+ " device control escape sequence", sc);
}
+   else
+ // TODO: Put '\[u]' support here.  Don't allow
+ // '\[u_]'.
+ error("special character '%1' cannot be used within a device"
+   " control escape sequence", sc);
   }
 }
 else if (!(tok.is_hyphen_indicator()
@@ -5668,7 +5680,7 @@ static node *do_special()
   c = '\b';
 else
   c = tok.ch();
-encode_char(&mac, c);
+encode_char_for_device_control(&mac, c);
   }
   return new special_node(mac);
 }









___

Reply to this item at:

  

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