[bug #65097] gropdf: one 'ps:' tag is now not processed

[Bjarni Ingi Gislason]

Follow-up Comment #5, bug#65097 (group groff):

  I have added this to my version of "gropdf":

elsif ($par=~m/exec decornone/)
{
#   skip processing
}
elsif ($par=~m/exec 0 setlinejoin/)
{
#   skip processing, already processed earlier
}
elsif ($par=~m/def grops begin/)
{
#   skip processing
}



___

Reply to this item at:

  

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

[bug #65097] gropdf: one 'ps:' tag is now not processed

[Deri James]

Update of bug#65097 (group groff):

  Status:   Need Info => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

Yes. Bjarni's else clause does not catch valid errors, not all ps: tags can be
processed into valid pdf. I support the ones emitted by our pre-processors and
macros (apart from the postscript underline function from mom).


___

Reply to this item at:

  

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

[bug #65097] gropdf: one 'ps:' tag is now not processed

[G. Branden Robinson]

Update of bug#65097 (group groff):

  Status:None => Need Info  

___

Follow-up Comment #3:

Deri, is this ticket invalid?


___

Reply to this item at:

  

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

[bug #65094] [bjarnigroff] [gropdf] hdtbl, picture "gnu.eps" missing in "mixed_pickles.pdf"

[G. Branden Robinson]

Update of bug#65094 (group groff):

  Status:None => Invalid
 Assigned to:deri => gbranden   
 Open/Closed:Open => Closed 
 Summary: gropdf: hdtbl, picture "gnu.eps" is now missing in
"mixed_pickles.pdf" => [bjarnigroff] [gropdf] hdtbl, picture "gnu.eps" missing
in "mixed_pickles.pdf"

___

Follow-up Comment #2:

This ticket does not report a problem with GNU _groff_.

The project does not attempt to build a file "mixed_pickles.pdf".

It does build "mixed_pickles.ps", a PostScript file.

As Deri explains in comment #1, one can't include Encapsulated PostScript in
PDF files.

One can't just render a document for any old _groff_ output device when that
document depends on output device-specific extensions.

Resolving as invalid. 


___

Reply to this item at:

  

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

[bug #64236] [eqn] rename chartypes "letter" to "slanted" and "numeral" to "upright"

[G. Branden Robinson]

Update of bug#64236 (group groff):

 Summary: [eqn] "digit" type seems to have a bad name => [eqn]
rename chartypes "letter" to "slanted" and "numeral" to "upright"

___

Follow-up Comment #2:

I [https://lists.gnu.org/archive/html/groff/2024-01/msg00048.html raised this
on the _groff_ list].


Because eqn uses Greek letters as mathematical symbols rather than
linguistic text, I think it is reasonable for it to explicitly access,
without loss of generality, upright and slanted symbol faces for "Alpha"
and "alpha", respectively.  I claim that by defining these keywords
(really macros, in the eqn language, except in GNU eqn, out of
laziness or optimization their defaults are set up in the lexer[2][3]),
they acquire _semantics_.  For practical purposes, the lowercase Greek
letters become slanted.

In fact, I am tempted to rename the "character types" in GNU eqn from
"letter" and "digit" (the latter being unused) to "slanted" and
"upright", respectively.  (Recognizing the old names for backward
compatibility, yadda yadda yadda.)




___

Reply to this item at:

  

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