The issue in the Subject line is being tracked as Savannah #66458. https://savannah.gnu.org/bugs/?66458
Any objections to including it in the goals for the 1.24 release? The patch seems ready to go, and it would be this release's only NEWS item applicable to pic. At 2024-09-30T07:03:05+0000, Duncan Losin via wrote: > I have written a patch to add support for drawing arbitrary polygons > in pic using the existing syntax for multi-segment lines. They can be > shaded and filled as expected of other closed objects. Examples > attached in polygon.pdf. > > There is also new syntax for referencing the positions of the vertices > and edge midpoints: > > - .v[er[tex]] expr > - .v[er[tex]] `expr' > - .p[oint] expr > - .p[oint] `expr' > > I must admit I have a very limited computer science education, so I > expect my implementation could use some improvements; feedback would > be appreciated. I'm not entirely pleased with how vertex_number is > set, but I struggled with polygon_object not being instanced until the > end of object_spec::make_line. That seems to be the general structure > of the program so I didn't want to change it, but perhaps there's a > better way to set the value, among other things. > > I've also included the following small documentation update. Where > referring to ordinals the documentation included the characters " ` " > and " ' " i.e. the grave accent and apostrophe. These are the correct > characters, but groff draws these as the left and right quotation > marks, which confused me when I tried to use this feature. I've > updated those characters to the appropriate escape sequences "\[ga]" > and "\[aq]" so that they appear properly. > > Future Work: If I understand it correctly (big if), PostScript > interprets all polygons as a path, much like how pic draws multi-line > segments. PostScript however can include arcs and splines as segments > and fill the resulting shape. It doesn't look like it would be > terribly difficult to implement this in pic, but it would be a lot of > work. I believe pic, groff, and grops would all need to updated to > accommodate the new drawing command. > > This process is all quite new to me so I appreciate your patience. > Happy to make any changes required. Thoughts on this? Meanwhile, for those who don't follow the ticket tracker or Git repository closely, I merged support for 16-bit PostScript fonts this week. https://savannah.gnu.org/bugs/?62830 This change, by TANAKA Takuji, also introduces a set of eight new font names recognized by multiple groff output devices. The idea is to smoothly support documents that use East Asian scripts (and may not require Western ones at all) in a portable way across output drivers. Quoting commit 76c81423da: These are intended as abstractions of faces to permit consistent naming while permitting customization, just as with the 12 text typefaces supported across output devices for Latin scripts in groff (three families of four styles each). These CJK font descriptions are not organized into groff font families, but are similar. CSH: Simplified Chinese, Hei style CSS: Simplified Chinese, Song style CTH: Traditional Chinese, Hei style CTS: Traditional Chinese, Song style JPG: Japanese, Gothic style JPM: Japanese, Mincho style KOG: Korean, Gothic style KOM: Korean, Mincho style Regards, Branden
signature.asc
Description: PGP signature
