Re: Proposed GNU troff behavior change: require end-of-input macros to exit
As far as I got, by playing around, the '\c' doesn't matter. It seems that the additional page comes from an additional call to the default page break. Using a custom trap, just disable it in your end trap: 8< .\" .\" run: groff em-test.groff > em-test.ps .\" .nr PAGE-trap 20c .nr PAGE-ll 13c .\" .de my-trap .tl '\\v'|\\n[PAGE-trap]u'\\h'|0'\\D'l \\n[PAGE-ll]u 0c 'bp \" matters: not .bp .. .\" .de your-end \c \" doesn't matter . ne 3v . sp (\\n[.t]u - 3v) .wh \n[PAGE-trap]u\" matters: disable regular trap . in +4i . lc _ . br Approved:\t\a . sp Date:\t\t\a .. .\" .wh \n[PAGE-trap]u my-trap .em your-end .\" .\".SF-std .\" XXX first line XXX .br .\" .sp |(\n[PAGE-trap]u-2.99v) \" matters: 3.01v get you one page only YYY last line YYY .\" 8< Without custom trap handling, one need to prevent the default one to engage: 8< .\" .\" run: groff em-test.groff > em-test.ps .\" or: groff em-test.groff > em-test.ps .\" .nr Pt 20c\" page trap .nr Pl 13c\" page length .\" .pl \n(Ptu .\" .\".de mt\" my trap .\".tl '\\v'|\\n(Ptu'\\h'|0'\\D'l \\n(Plu 0c .\"'bp \" matters: not .bp .\".. .\" .de ye\" your end .\"\c \" doesn't matter . ne 3v . sp (\\n(.tu - 3.01v) \" prevent another page break .\".wh \n(Ptu\" matters: disable regular trap . in +4i . lc _ . br Approved:\t\a . sp Date:\t\t\a .. .\" .\".wh \n(Ptu mt .em ye .\" .\".SF-std .\" XXX first line XXX .br .\" .sp |(\n(Ptu-2.99v) \" matters: 3.01v get you one page only YYY last line YYY .\" 8<
Re: Zero Width Space (was Re: How to print a literal '.' as the first character in a line?)
I see an argumentation of user model against the system model point of view. That will never do, because they are different. Secondly, you are fighting about the name (identifier) of an escape sequence using arguments valid of an description. That doesn't make sense. Generally the name 'zero with space' puts '\&' in line with \|, \^, \0 and \~, what gives structure and therefore it is better to remember. If '\&' stands out of that group, add an extra sentence. Moreover, if you think that '\&' is an important topic, give it an extra paragraph. If not, from the user (typesetter not programmer) point of view, give it a name but drop it. Finally, don't treat documentation like source code. For instance, writing the same thing again without repeating any word, favors the reader _and_ challenges the writer, because that forces him to drop his tunnel vision. One don't have to be right but have to be understood. Purpose matters, doesn't it?
Re: pic doesn't center when i use a macro
I did three things:
1) wrapped the what_should_become_a_string inside a custom object [].
(See the braces of the macro.) This makes the 'if' statements (and
more) possible.
2) I placed those object directly, as you can do with any graphic object
(incl. strings) in pic. Annotation labels are way limited.
3) lazy writing
On Thu, 4 Nov 2021 09:23:26 +0100
Marc Chantreux wrote:
> hello Holger,
>
> > box width w height margin with .nw at last box .nw dashed
> > label_for(layer) at last box.c
>
> I really don't know why but yes: it works. Now i have a workaround
> in my hand.
>
> On the other hand: the more i saw the Tadziu's code, the more I like
> it for its clean separation between porcelain and plumbing. The only
> thing you have to read is:
>
> layer("Entête Ethernet")
> layer("Entête IP")
> layer("Entête TCP")
> layer("Donnees applicatives")
>
> Thanks
> marc
>
>
>
Re: pic doesn't center when i use a macro
.PS
define label_for {[
if $1 == 0 then { "Entête Ethernet" } else {
if $1 == 1 then { "Entête IP"} else {
if $1 == 2 then { "Entête TCP" } else {
if $1 == 3 then { "Donnees applicatives" } else {
} } } }
]}
w = 3 ; h = 2; margin = .2 ; tr = 2 * margin
for layer = 0 to 3 do {
s = layer * margin
box width w height h with .sw at (s,s)
box width w height margin with .nw at last box .nw dashed
label_for(layer) at last box.c
w = w - tr
h = h - tr
}
.PE
On Mon, 1 Nov 2021 19:57:15 +0100
Marc Chantreux wrote:
> hello groffers,
>
> I wrote the following code to illustrate the DOD model encapsulation.
>
> sadly: the label of the layers are not centred. it seems to be
> relative to the fact i use a function as it works fine when i replace
> label_for(layer) by a simple string
>
> like
>
> box width w height margin \
> with .nw at last box .nw dashed \
> "" label_for(layer) ""
>
> by
>
> box width w height margin \
> with .nw at last box .nw dashed \
> "" "eat the road, jack" ""
>
> I can do something more manual but i really would like to take
> advantage of the expressivity of pic. Any other comment is also
> warmly welcome.
>
> regards,
> marc
>
> # compiled with
> # scan.ps: scan.ms ${deps} ; groff -skp -ms -mfr $< > $@
>
> .PS
>
> define label_for {
> if $1 == 0 then { "Entête Ethernet" } else {
> if $1 == 1 then { "Entête IP"} else {
> if $1 == 2 then { "Entête TCP" } else {
> if $1 == 3 then { "Donnees applicatives" } else {
> } } } }
> }
>
> w = 3 ; h = 2; margin = .2 ; tr = 2 * margin
> for layer = 0 to 3 do {
> s = layer * margin
> box width w height h with .sw at (s,s)
> box width w height margin with .nw at last box .nw dashed ""
> label_for(layer) "" w = w - tr
> h = h - tr
> }
> .PE
>
>
Re: includes in eqn & pic. [Re: GNU eqn question/suggestion]
On Sat, 28 Nov 2020 01:32:33 +0100 Tadziu Hoffmann wrote: > > eqn does well, however .PS/.PE doesn't seem to be processed by > > [g]pic on inserting. > > > > I compiled using: groff -e -p test.groff > test.ps > > The eqnrc is inserted by eqn, but in the pipeline run by > "groff -e -p", eqn runs *after* pic, so pic never sees this input > and cannot act upon it. Since pic does not (as far as I know) > have an analogous automatic startup file, you have to move the > pic stuff out of the eqnrc and into a "picrc" that you must > include manually: > > groff -e -p picrc test.groff >test.ps ... of cause. One only need the hint. Thanks
Re: includes in eqn & pic. [Re: GNU eqn question/suggestion]
On Fri, 27 Nov 2020 15:17:49 +0100 Tadziu Hoffmann wrote: > > edit: ~/.groff/eqnrc > > define eqnrc_version % 0.0 % > > > > and got "define eqnrc_version % 0.0 %" literally included on top of > > the created .ps-file. > > Despite the name, eqnrc can contain all sorts of troff input, > not only stuff for eqn, and is simply inserted into input stream. > Material for eqn must be contained within EQ and EN: > > .EQ > define eqnrc_version % 0.0 % > define member % type relation \[mo] % > define emptyset % \[es] % > .EN Thanks. eqn does well, however .PS/.PE doesn't seem to be processed by [g]pic on inserting. I compiled using: groff -e -p test.groff > test.ps Files attached. test.groff Description: Binary data test.ps Description: PostScript document eqnrc Description: Binary data
includes in eqn & pic. [Re: GNU eqn question/suggestion]
On Fri, 13 Nov 2020 13:43:56 +0100 Tadziu Hoffmann wrote: > > element of set is '\[mo]'. Would it still be logical to expand > > the synax for eqn to add it as a keyword? > > I would just put something like > > define member % type relation \[mo] % > define emptyset % \[es] % > > and so on into my own eqnrc file, then you can say > > .EQ > x member emptyset > .EN > > and so on. > > (Set GROFF_TMAC_PATH to the name of the directory that contains > the eqnrc, so that it will be found automatically.) Hi, I'd: run: export GROFF_TMAC_PATH=$GROFF_TMAC_PATH:$HOME/.groff edit: ~/.groff/eqnrc define eqnrc_version % 0.0 % and got "define eqnrc_version % 0.0 %" literally included on top of the created .ps-file. CML: preconv -e $preconv_format $dir/$file.groff | grap | pic -U | \ tbl | eqn | groff -Wbreak -U -Z | grops -pA4 > $dir/$file.ps However, since I think on eqn I missed something, is it possible to include defines into pic as well? Can one have a pic-macro-package? Regards Holger
Re: [groff] Creating a numbered list without macros
On Wed, 22 Aug 2018 11:55:26 -0400 Peter Schaffter wrote: > On Tue, Aug 21, 2018, Holger Herrlich wrote: > > > On Mon, 20 Aug 2018 15:24:39 -0400 > > > Peter Schaffter wrote: > > > > > set and change every applicable type parameter: family, font, > > > size, colour, leading, spacing, indent, quad, fill, and vertical > > > placement. > > > > > > In other words, mom expands creative options rather than > > > limiting them. That's the whole point. > > > > Font height \H'' missing. > > I'm not sure what you're saying. That \H'' functionality is > missing from the mom macros? It's there. Raising or lowering > font height (Y-axis) has the corresponding effect of condensing or > expanding (X-axis). Mom exploits the latter and uses \H'' to create > pseudo-condensed and pseudo-expanded font effects, invoked inline > with \*[CONDENSE] or \*[EXPAND]. > > Nothing prevents using \H'' itself if, conceptually, you prefer to > think of the type deformation as stretching/squashing vertically > rather than horizontally. > > I may be misunderstanind what you're saying, though. I don't know mom. You just weren't name it (\H'') but said "everything", while talking about facts. Well generally, that one can use a groff feature, does not mean, it's the macro package's feature. Think about embedded PostScript. And being "not prevented" from something, still needs to watch out for possible side effects. It's not a so called supported entry. But I don't say mom is evil. And it cannot be everybody's darling. I just say, one may longing for his own macro set.
Re: [groff] Creating a numbered list without macros
On Mon, 20 Aug 2018 23:22:44 +0200 Tadziu Hoffmann wrote: > > A macro package does not hide the controls any more than writing > > macros yourself does. A macro package aggregates the requests > > needed to perform typesetting functions for convenience, not > > opacity. > > Well said. Isn't it an over generalization? Doesn't technology consist of compromises as well? > I would like to add that I sometimes get the impression that people > think that once they use a macro package, raw formatter requests > should not be used anymore, as they somehow taint the "purity" of the > manuscript. (This idea also appears to exist among some LaTeX users.) > > But this is of course nonsense. The purpose of macro packages > is not to *limit* what you are *allowed* to do, but to *help* > you in what you *want* to do. And we should keep in mind that one of > the core uses of macros is not to save a few keystrokes in marking up > the manuscript (although it helps), but to maintain *consistency* > across the entire document.
Re: [groff] Creating a numbered list without macros
On Mon, 20 Aug 2018 15:24:39 -0400 Peter Schaffter wrote: > set and change every applicable type parameter: family, font, size, > colour, leading, spacing, indent, quad, fill, and vertical > placement. > > In other words, mom expands creative options rather than limiting > them. That's the whole point. Font height \H'' missing. > > The framework takes away flexibility. > > No. A *poorly implemented* framework takes away flexibility. A well > implemented one adds to it. Even if the framework is perfectly designed, if its intended scope covers HTML as well, it likely has limited postscript support. > > So to create business cards I had to do it myself from the > > scratch. > > Mom provides a sufficiently flexible framework that you could have > created the business cards from scratch using only mom macros and > not one single low-level groff request. I know, I've done it. > Eight-up with logos, crops, and register marks. > > > OKAY, that's the idea. A framework doesn't provide smaller > > entities (the UNIX thing) to be more creative (not only > > graphically). > > I want to insist that you're talking about *inadequate* frameworks, > about which all your comments are true, not well-designed ones. A > well-designed framework is one that supports you when you want to > wander down the creative path. Well, I don't want to blame inadequate frameworks. A tl;dr-user may go well using an inadequate framework. Nobody can know everything. Your claim assumes that perfection is possible and finally everyone will go for it. Instead I want to blame certain problems using certain frameworks, to categorize some and find the ones that blend in with me. By creativity I also mean how to draft macros, BTW.
Re: [groff] Creating a numbered list without macros
Sorry, the former mail was an Hot-Key-Accident (sticky keys and focus follows mouse) and my first reply a misdirecting filter rule. While it's kinda hard, using few words, to claim that here is use for private macro sets between plain groff and "don't care" frameworks, I was trying and then .. Uhm, but it is out... and this part is valid: Here are some reasons to avoid frameworks like Latex or mom. (You may ask yourself why I mention Latex as well and further on talk about frameworks in general. Well what's because I doesn't use mom. Therefore some of my claims may more or less not be applicable to it. On the other hand, I don't think.) First lets assume that here is a diametral contradistinction between plain groff and a macro package like mom in terms of user interface. The first provides you all the controls to type set. The latter hides that controls as much as possible, claiming the writers perspective. Here is a reason to do so, because mixing up text and groff requests will disturb reading/writing. Document writing using markup will always suffer this problem. So if you wanna write, you will end up with a macro set. Why not an existing one? For me, I want to use tools that preserve creativity. But a framework desires to make things easy. (As a rule of thumb: Always avoid people claiming that.) But the kindergarten teacher's "making things easy" is different to providing a professional tool that do exactly that it claims to do--therefore is "easy to use". Very general nowadays: - Tools don't simplify your task. A Tool simplifies the accomplishment. - Encapsulation is not hiding! - And don't confuse to learn with to obey (learn the ticket window). The framework takes away flexibility. so to create business cards I had to do it myself from the scratch. Programming languages as well as GUIs are just instances of an user interface. Therefore I like the design of an multi level (high,low) API. OKAY, that's the idea. A framework doesn't provide smaller entities (the UNIX thing) to be more creative (not only graphically). Sorry again, Holger On Thu, 16 Aug 2018 11:55:59 +0200 Holger Herrlich wrote: > On Sat, 11 Aug 2018 18:12:18 +0200 > Ingo Schwarze wrote: > > [context removed however] > > Oh, and why don't you just pick one of the existing macro sets? > > Here are some reasons to avoid frameworks like Latex or mom. (You may > ask yourself why I mention Latex as well and further on talk about > frameworks in general. Well what's because I doesn't use mom. > Therefore some of my claims may more or less not be applicable to it. > On the other hand, I don't think.) > > First lets assume that here is a diametral contradistinction between > plain groff and a macro package like mom in terms of user interface. > The first provides you all the controls to type set. The latter hides > that controls as much as possible, claiming the writers perspective. > > Here is a reason to do so, because mixing up text and groff requests > will disturb reading/writing. Document writing using markup > technologies will always suffer this problem. So if you wanna write, > you will end up with a macro set. > > So why not an existing one? > > For me, I want to preserve creativity. Well the framework desires to > make things easy. (As a rule of thumb: Always avoid people claiming > that.) But "making things easy" is different to providing a > professional tool that do exactly that it claims to do--therefore is > "easy to use". > > Encapsulation is not hiding! > > Tools don't simplify your task. A Tool simplifies the accomplishment. > > And don't confuse to learn with to obey. > > > All of this nifty differences emerging especially along software > _solutions_. It's not special to groff or mom. > > > writing a macro set (not a high > priority in my life, but does what I want), is to develop an API (for > my macro set), that give me control about independent tasks and > defines only as few as possible globals. (You cannot go without.) > Whereas the globals being an singular institution. However, I'm not > being what better, except what I can change it myself. > > independent tasks > singular globals > no interference with plain groff temporal variables > > > > ave an API > () to become Not only valid for groff macro sets, the sole concept of > beginning with defining a frame in order to use the framework debars > it. A framework only is of use, if you fit to the dedicated use case > and know it in detail. > > Therefore the acceptance of a macro set goes along with its concept > and the documentation of it (the concept not the functions only). > > > > So macro packages for man pages are perfectly fine. Clear and easy use > case. &
Re: [groff] Creating a numbered list without macros
On Sat, 11 Aug 2018 18:12:18 +0200 Ingo Schwarze wrote: [context removed however] > Oh, and why don't you just pick one of the existing macro sets? Here are some reasons to avoid frameworks like Latex or mom. (You may ask yourself why I mention Latex as well and further on talk about frameworks in general. Well what's because I doesn't use mom. Therefore some of my claims may more or less not be applicable to it. On the other hand, I don't think.) First lets assume that here is a diametral contradistinction between plain groff and a macro package like mom in terms of user interface. The first provides you all the controls to type set. The latter hides that controls as much as possible, claiming the writers perspective. Here is a reason to do so, because mixing up text and groff requests will disturb reading/writing. Document writing using markup technologies will always suffer this problem. So if you wanna write, you will end up with a macro set. So why not an existing one? For me, I want to preserve creativity. Well the framework desires to make things easy. (As a rule of thumb: Always avoid people claiming that.) But "making things easy" is different to providing a professional tool that do exactly that it claims to do--therefore is "easy to use". Encapsulation is not hiding! Tools don't simplify your task. A Tool simplifies the accomplishment. And don't confuse to learn with to obey. All of this nifty differences emerging especially along software _solutions_. It's not special to groff or mom. writing a macro set (not a high priority in my life, but does what I want), is to develop an API (for my macro set), that give me control about independent tasks and defines only as few as possible globals. (You cannot go without.) Whereas the globals being an singular institution. However, I'm not being what better, except what I can change it myself. independent tasks singular globals no interference with plain groff temporal variables ave an API () to become Not only valid for groff macro sets, the sole concept of beginning with defining a frame in order to use the framework debars it. A framework only is of use, if you fit to the dedicated use case and know it in detail. Therefore the acceptance of a macro set goes along with its concept and the documentation of it (the concept not the functions only). So macro packages for man pages are perfectly fine. Clear and easy use case. Macro packages for articles, from my point of view, miss the point and lack design. To transform an big ASCII text into a printout that becomes an A6 book, I have to do by myself anyway. The same is true for business cards and calendars, for instance. Further, it often turns out to be hard to integrate your own (business card) macros into a framework or vice versa, because of side effects, one are not aware. ps: Plain groff is fun to work with!
Re: [Groff] ps: import of an EPS file with binary data
BTW, In the case of jpeg-files I finally switched to gimp's fu-script to convert pictures to groffable eps-files. Gimp seems to me as of very high quality. I attached a pbm version of the script still leaving jpeg artifacts as comments. Further info of fu-script functions is provided by gimp's Procedure Browser under the help menu entry. Regards Holger On 07/05/2012 08:28 PM, Steve Izma wrote: I'm using convert (from imagemagick) to crop and convert pbm images into encapsulated postscript. When I prefix the output filename with eps2: I get a very compact EPS file where the image data is contained as binary like this: userdict begin %%BeginData:72200 Binary Bytes DisplayImage [a few lines of integers] [72200 binary bytes, presumably] %%EndData end The resulting image is displayable (e.g., in okular), but when it gets imported into groff with either .PSPIC or \X'ps: import ...' only the first part of the binary gets cleanly imported into the PostScript output (up to the first newline character) and the rest becomes a series of ^M's -- which print black. I realize that up to now all the images I've been converting to EPS for use in groff contain the image in ASCII format, but I was hoping to reduce file size with this convert output. As far as I can tell, the output conforms to PS LanguageLevel 2 (flagged by the eps2: prefix in the convert commandline). Is there some other flag or option I've overlooked? Thanks, -- Steve mkEpsFromPbm-gimp.sh Description: Bourne shell script
Re: [Groff] rotating a line of text turns a hole page
Thank you, that single line does the job.
Lg Holger
On 03/30/2012 12:30 AM, Tadziu Hoffmann wrote:
However, is it possible to fix it at the groff level.
I don't think so.
Have to correct myself. If device escapes count as at the
groff level then it is possible with the following code:
\X'ps: def \
systemdict /setdistillerparams known \
{ /AutoRotatePages /None setdistillerparams } if'
[Groff] rotating a line of text turns a hole page
Hi, I have a problem setting a line of rotated text (test.groff). Output device is post script. Here is some processing (test.sh) that all succeeds but finally on a call to ps2pdf the page containing the rotated line itself is rotated by 180deg. Reasons unclear. A preceeding void helped, dropping \[:u] also. However, at the production groff-source non of that works. The issue first occured for my own rotate macro: .de RT \\X'ps: exec gsave currentpoint 2 copy translate -\\$2 rotate neg exch neg exch translate' \\$1 \\X'ps: exec grestore' .. Since post script is ok, it seems to be a problem of gs at producing pdf. However, is it possible to fix it at the groff level. Regards Holger \ .ft HB .ps 48 .vs 50 \H'48' PAGE 1 .bp PAGE 2 .bp .\void \ correcting effect .PS line invis up 1 PAGE 3\[:u] aligned above # fails #line invis up 1 PAGE 1 aligned above # ok .PE .bp PAGE 4 .br test.sh Description: Bourne shell script
Re: [Groff] Using variables from register within fractions or equations
On 02/17/2012 02:45 PM, maouinin wrote: \h'\\nwu'\v'1m'\\*n\v'-1m'\h'\\nwu'\\$2 father on: \*n \ recalls string of name n \v'-1m' \ vertical move up one (1) line (m), this is a value. Note that \v for instance will interpret values by a default unit, used in absence of one given. Thereas Troff internally stores ... dimensions in units that correspond to the particular device ... (Troff Users Manual, 1992, Ossanna/Kernighan). So in using number registers, i always append 'u' (means basic unit). Otherwise things will be correctly shifted out of sight, leaving you clueless that happend. Lg Holger
Re: [Groff] table column spacing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 groff-file: .TS center box; l s s l c s s c s s l |6 n0.5i c1 n |6 n1 c1 n. Format DIN-A .sp .5 mm in _ DIN-A0 841 \[mu] 118933.11 \[mu] 46.81 DIN-A1 594 \[mu] 841 23.39 \[mu] 33.11 DIN-A2 420 \[mu] 594 16.54 \[mu] 23.39 DIN-A3 297 \[mu] 420 11.69 \[mu] 16.54 _ DIN-A4 210 \[mu] 297 8.27\[mu] 11.69 DIN-A5 148 \[mu] 210 5.83\[mu] 8.27 _ DIN-A6 105 \[mu] 148 4.13\[mu] 5.83 DIN-A7 74 \[mu] 10 2.91\[mu] 4.13 DIN-A8 52 \[mu] 74 2.05\[mu] 2.91 DIN-A9 37 \[mu] 52 1.46\[mu] 2.05 DIN-A10 26 \[mu] 37 1.02\[mu] 1.46 .TE produces: mkgroff papierformate-din476.groff tbl:standard input:44: `.' not last character on line tbl:standard input:44: giving up on this table where mkgroff is: grap $dir/$file.groff | pic | tbl | eqn | groff -Z | grops -pa4 \ $dir/$file.ps - -hh- On 04/08/2011 08:05 AM, Werner LEMBERG wrote: How about floating point distances. I got an error, cause of . finalizes the preamble. (Of cause one may use 0 distances at the preamble and put horizontal spaces in the table data.) Sample, please. Werner -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNpeNHAAoJEOA4scJwSAQs2i0IAI3po7zphNPgO0GPWMPr9eIn O1Se8xF1/F5ktZUWwvca2qFxafN8K3L0DxDa0vmoAYhg6/+ZqS9LaIkdriRTdO9v /cu+8UgP3klKwIRdlh5mh2OEnSNBrqTEAxXHpggzCe51UHtR4wEQp1Hbbzcc4sXh WthTrABtSoTm6Dvznhh9g3qv/oeGuXu1N7VANBrKkc4Nv2HVcBDdhuzpY7zfdXyy zGD1aN3Hl5zDLxUjMn27k4r2+nwNgZ5xnAGO1stLeKCBrmyZ1ACqy1wLElqrOni3 L2kN89V9aXhMicqRnpZ3pdsW6zyjbpmQ9h5Ws/KQV3MdfKnakMy1hzqkbTllS5s= =SdT2 -END PGP SIGNATURE-
Re: [Groff] table column spacing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How about floating point distances. I got an error, cause of . finalizes the preamble. (Of cause one may use 0 distances at the preamble and put horizontal spaces in the table data.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNnic9AAoJEOA4scJwSAQsJhwH/2G7cKoFajoJW5xJlgwLji9j +Yk3OtEbHu47CRJ8ZRygq05E017a9sfvRPcJ1ivcLcyV08CNWvbpnJxVkE0tGeNO tUqdRatC+hDgC5o3ltAQSUaMioRpACIp6/88aQ6XPtTI9b4c0OKVS17c2B//lod/ LrDDyGf6nDXQ51Akt+Jq0+MjncKjTr8uvqZsEHvilMZoB6bI4g7OxweutJyk4+ci kCN09FbcBB3Uqww+Yk7TDg5TFQtqDresj6iGqvSmcvb6k7SesDDZu53+YL4reDhd ykph1le1I8KaRcRvuTs9z24d7EsylrLiqzRaYeK1s02rXuyrS57s3BZPUtlATxM= =IWSk -END PGP SIGNATURE-
