From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org> Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id CO6QNzEdY2dIHQEAqHPOHw:P1 (envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>) for <larch@yhetil.org>; Wed, 18 Dec 2024 19:06:26 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id CO6QNzEdY2dIHQEAqHPOHw (envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>) for <larch@yhetil.org>; Wed, 18 Dec 2024 20:06:26 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cqdqh8Eb; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1734548785; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=tO55a0JYVk91PCJtEhpKCq2Jh/Yg6oj+KndTqLAUwRw=; b=qGOa/XfR1fJsl2R7O8JUwaQO5x90vRPkGa2OE45sBJCAZovfLCGTY1IsMmiAG1+HGE7EzG lAumeQStOgAId2VT29IndHkzaLtwUo/+eMA2qaQtaMeGO6DF02dowZCxJ1qs9GtQiK7i5q 6LwrtwzoQF6s2SgtojLavLyydBB1Q+wf0l5hxzGUYQO+PYoocrsG7tJ79v5q+ULVqQb6jm 4VA1r3xPcn8fQWMfZqQ0BJ7Or0JqOfCBteXRI9PHIbR1jNkB58DGPGN/QYTCtTOffnbYBC 2iODdKrNQ4rwy50DYvi/RN034+A8/z2FW/T1FRWq872Me3rRgyn73U5sX+1xOg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1734548785; a=rsa-sha256; cv=none; b=gOqwTNmDw6inW2Xiv9/bnJ0fGIRQnxsBOZTm3ufOKtL8HP4n2xHeVfW+Hi79MstwxAI4oJ HtAPFIfJ9GcMsxJay3RKZVVZ5YgXlTEnn2hvGeFE/GsefLgsP3PhA/mpA6OYRPTdZl+X+K WbrBchoo+cV3FnVeDoyX6mo/1W8jI6DsG5A/jS9BrRO85EGsuw6ecydUQOpCZpgx7MD8gg +y2nc6AxZru7Ajbb4A0Csj19sBsjqLHDFNQ05q7w2KklD7R6roIUpg3RY6DfGOnkWc1/WT p9ltM/iUHQkfOdzFmXDLVdfX57e1LLzGcDkusW7D7lREJPgYmFcbl8cfpsaEhQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cqdqh8Eb; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AEDFF47A92 for <larch@yhetil.org>; Wed, 18 Dec 2024 20:06:24 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <emacs-orgmode-bounces@gnu.org>) id 1tNzMV-0007ZX-Un; Wed, 18 Dec 2024 14:05:35 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <g.branden.robinson@gmail.com>) id 1tNxjR-0001kZ-Af; Wed, 18 Dec 2024 12:21:12 -0500 Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <g.branden.robinson@gmail.com>) id 1tNxj5-0007iJ-2R; Wed, 18 Dec 2024 12:20:52 -0500 Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-71e2bc5b90fso3177897a34.0; Wed, 18 Dec 2024 09:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734542444; x=1735147244; darn=gnu.org; h=in-reply-to:content-disposition:mime-version:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=tO55a0JYVk91PCJtEhpKCq2Jh/Yg6oj+KndTqLAUwRw=; b=cqdqh8Ebx5nSPlfztJuWcHNGpic/RBrL2PDDcRUoXR8Fl6kA050s/5UleHEwTknqG5 aeLYrUATA/Cu6C43rKc0DmJ5S8Mo6bSlwrMld0an3oRpQZ5v4bYol5n6SpklEHwYXx59 1ln1SmNXdhuY0XCSvqy4qHW7BAFkYU4mvPh2m+D+viIDYEiMcV+dMRdIh6Al3X/+UJnG UuPB5xnujl5OcwZpT1XmzT9ANOa3nntCwVJPppO4nwGXS97DoR+5CT8ObMDqPHKjrlPY xFARyZaYJi9m897oGt3PeRU1Px/QzDY/u4ZwHv2S8HzLjBWJWWjdoPTDx4gleWmqd/C4 1woA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734542444; x=1735147244; h=in-reply-to:content-disposition:mime-version:message-id:subject:cc :to:from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tO55a0JYVk91PCJtEhpKCq2Jh/Yg6oj+KndTqLAUwRw=; b=CxDBK8zKDeK7g4Vg7jI0LVIdme5N16DCLtWs8TIDehCwkA0vbq24SiPiz+qeWeN2Uc +2vhaHc5oin5qzrMJ/sgn9LqXr2i8Bq48bHaRqW6PRp+Z22+kMH9Th3f3M5po3yqgjoW n9G42ybJ2tk5vj6UKpsCLAtp4+wF1GCnPNy+L//rw3t28CDHGWE+L7RxuE1c7KeX7WV+ BaBhWygfIIjzFh3s22M2xcBLmpMTn2nqkoxauQq9RKQwp4938w/U6i//jL+r/TsDjpdJ 71u+KQnRP5bvzpzdnEO77bvW/fqxGswXRcmq8EMHJbZ8NHoZ5LA/wDULdYk9JX+Cy9H/ +Fhw== X-Gm-Message-State: AOJu0YxO34th5rLR3+KvxAAsGCuueBHd5UjWovtHQWPIafk3q20T5Rfi H0Ed8lw9ge8ehuondP/A9OBHN63Goy2nCFMuj/kyQRDgk2D/0izJ9AMHvw== X-Gm-Gg: ASbGnctORY3Vn4BtEk/W+vBad/8TJ0TzSowkKC9n+kFXaOxf2CS52CgTNCu5G2O4JW3 r/CB8BmHhqaqd3YSvtzocz+t5Lh2aXjUk5uSBZUHSbgSE2aI+vyuJHz5Z7Q+/bovGKougAn6JMH 00KAuTZJaMrIG33DoS3YHP0lfE4wEhdBaQIUu9bvo7aptk7oYXZRAo0Sz9EhrpuCsNDyICNKSBo E5O7NSm86OaGwhLzh2Ar0Eko47DuyRwkYHsSP1kB1e8lP8= X-Google-Smtp-Source: AGHT+IFivQn5Nf4AKeKkgmfVlYZ7yawn//gKzssiWms/0ITn551UUIdYW34KHtS99iIIhBkJUJ7CEg== X-Received: by 2002:a05:6830:2704:b0:719:dd54:ee79 with SMTP id 46e09a7af769-71fb759bf54mr2553808a34.15.1734542443657; Wed, 18 Dec 2024 09:20:43 -0800 (PST) Received: from illithid ([2600:1700:957d:1d70::49]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-71e48307d7csm2626189a34.14.2024.12.18.09.20.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Dec 2024 09:20:42 -0800 (PST) Date: Wed, 18 Dec 2024 11:20:40 -0600 From: "G. Branden Robinson" <g.branden.robinson@gmail.com> To: emacs-orgmode@gnu.org Cc: groff@gnu.org Subject: Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)] Message-ID: <20241218172040.tyytdhbyl7annyli@illithid> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m62nbg7v6n44c7z7" Content-Disposition: inline In-Reply-To: <87v866jsou.fsf@debian-hx90.lan> <87frx7moh8.fsf@localhost> <87h6hcia9y.fsf@debian-hx90.lan> <878r2mxtjw.fsf@localhost> <20240314214651.GB324558@celephais.dreamlands> Received-SPF: pass client-ip=2607:f8b0:4864:20::32f; envelope-from=g.branden.robinson@gmail.com; helo=mail-ot1-x32f.google.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 18 Dec 2024 14:05:34 -0500 X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>, <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode> List-Post: <mailto:emacs-orgmode@gnu.org> List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>, <mailto:emacs-orgmode-request@gnu.org?subject=subscribe> Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: -10.86 X-Spam-Score: -10.86 X-Migadu-Queue-Id: AEDFF47A92 X-TUID: D05YL958owpy --m62nbg7v6n44c7z7 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)] MIME-Version: 1.0 [looping in groff list; please reply to it as well, as I am not subscribed to emacs-orgmode] Hi Xiyue, Ihor, and Jeremy, I stumbled across this thread while researching problems have encountered with groff, which I maintain for the GNU Project. At 2024-02-29T23:51:29-0800, Xiyue Deng wrote: > "mu4e"[1] (a popular Emacs mail client) uses Org to generate its > manpages. However, the generated output contains macros that are not > understood by groff. After some debugging, Jeremy traced this back to > the macro "\fC" used in ox-man.el[2]. Strictly speaking, that's an escape sequence, not a macro. > Git history shows that this may have been there since the beginning. > We tried to find a documentation for the "\fC" macro but has not been > able to find one. Here's some historical background. Some may want to skip it. --- begin background --- `C` is a non-portable font name. Few font identifiers _are_ portable across the history of troff. When Brian Kernighan refactored Joe Ossanna's original troff for device-independence circa 1980, digital fonts were in their infancy and not generally portable across hardware devices as they are now. The original device target for Unix troff, the Graphic Systems, Inc. (later acquired by Wang Laboratories, Inc.) C/A/T machine, did not have digital fonts. It was a phototypesetter: its fonts were glyphs etched on glass plates mounted in a rotating mechanical carousel and magnified with an optical lens to the desired type size, then flashed to photosensitive paper. Kernighan perhaps did not foresee that people targeting multiple output device from a single master document might be able to avail themselves of the same typefaces, or at least metrically compatible ones, across devices, and so made no provision for font aliasing or renaming. (You could wangle it, perhaps, by restricting oneself to numerical "mounting positions", but this seems to have been a seldom-taken recourse in surviving *roff documents of the 1980s that have come to my attention.) --- end background -- > Jeremy suggests that "C" may be an old alias for Courier, and if > that's the case it should be changed to "\f[CR]". Would be great if > Org people can confirm. That is good advice and it is what I recommend if you're writing in "raw" roff. The context of the discussion is not ultra-clear to me; is ox-man.el a replacement for the old GNU Emacs man pager, "woman"? If what you're dealing with is man pages, I (and mandoc(1) maintainer Ingo Schwarze) discourage the use of formatter features for font selection. Use the man(7) package's macros instead. I'll return to this point below. At 2024-03-03T13:30:59+0000, Ihor Radchenko wrote: > This is not an unknown problem. AFAIU, the \fC macro is widely used > for troff, although it is not supported by groff. Check out the > ongoing discussion at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1049968#15 It _is_ supported, however there are some confounding factors. Historically, groff has quietly remapped the font name "C" to "CR" (Courier roman, see below). However this was done only for the "ps" (PostScript) output device (and PDF via file inclusion). https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/ps.tmac?h=3D1.23.0#n8 This means that the font name did not exist, and was not supported, on terminal devices, which is what I suppose ox-man.el is using to stage the rendered man page before doing whatever it does to make it look nice in an Emacs window. So, when you try to switch to font "C" or "CR" on a terminal device, nothing happens. Here comes the next complication. Historically, groff also did not throw warnings when a nonexistent font was selected. In groff 1.23.0, it started emitting these warnings. People mistook this for withdrawal of "support" for font names "C" and "CW" (and occasionally others). What's actually happening is that, when rendering for a device other than "ps" or "pdf", they are being warned of a no-op that they weren't warned about before. Nothing about the rendering of the document actually changed. https://lists.gnu.org/archive/html/groff-commit/2022-06/msg00114.html This experience convinced me that these legacy font names are more trouble than they are worth, so for groff 1.24 (for which, now that I have a fencepost account, I hope to make a release candidate available soon), we're starting a deprecation cycle for them. https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=3Ddb49abe9ee9035f2= 48f0893b4a1beb4ce3db8e38#n245 >> The best solution known to me is to use an extension to the man(7) >> language. It first appeared in Ninth Edition Unix (1986) and was >> adopted by a groff release in 2009. That is the `EX`/`EE` macro >> pair, which sets a monospaced display. (In other words, filling is >> disabled and a monospaced font selected if necessary.) Yes. At 2024-03-11T17:06:17-0700, Xiyue Deng wrote: > I'm not very familiar with roff so my understanding may be off. > According to the `Safe subset' section in man(7), they mentioned the > following: >=20 > ,---- > | Font changes (ft and the \f escape sequence) should only have the > | values 1, 2, 3, 4, R, I, B, P, or CW (the ft command may also have > | no parameters). > `---- >=20 > Does it mean `\fC' should be replaced by `\f[CW]'? No. The Linux man-pages version of man(7) is going to be (or already has been, in a recent release) withdrawn in favor of groff_man(7), which along with a new page for groff 1.23.0, groff_man_style(7), has been intensely worked on for the past seven years to make man page composition (and, to an extent, reading) a less mysterious process. https://lore.kernel.org/linux-man/7f7f2644-d408-969b-6916-ee9cae0962b9@kern= el.org/ At 2024-03-13T11:25:23+0000, Ihor Radchenko wrote: > man 7 groff has >=20 > Fonts often have trademarked names, and even Free Software fonts > can require renaming upon modification. groff maintains a > convention that a de=E2=80=90 vice=E2=80=99s serif font family is g= iven the name > T (=E2=80=9CTimes=E2=80=9D), its sans-serif family H (=E2=80=9CHelv= etica=E2=80=9D), and its > monospaced family C (=E2=80=9CCourier=E2=80=9D). Histori=E2=80=90 c= al inertia has driven > groff=E2=80=99s font identifiers to short uppercase abbreviations of > font names, as with TR, TB, TI, TBI, and a special font S. >=20 > So, \fC refers to "Courier". Yes, but. The "C" here, in groff, refers to a font _family_, not a fully resolved font name. In groff, following the precedent of Adobe PostScript, four styles of Courier are available: Courier roman, Courier italic, Courier bold, and Courier bold-italic: CR, CB, CI, and CBI. https://www.gnu.org/software/groff/manual/groff.html.node/Using-Fonts.html#= Using-Fonts Because of the aforementioned aliasing, you could "get away with" saying `\fC`, because, when rendering for "ps" or "pdf", `C` would be remapped to `CR` for you, but that was no help for terminal output devices. They never were able to select such a font, and in groff 1.23.0, the formatter started warning about this. > I did not find any text description of CW font, but my groff > installation has usr/share/groff/1.23.0/font/devdvi/CW font spec: >=20 > name CW > special > ... Yes. This is a tangentially related issue. As grodvi(1) says: Typefaces grodvi supports the standard four styles: R (roman), I (italic), B (bold), and BI (bold=E2=80=90italic). Fonts are grouped into families= T and H having members in each style. =E2=80=9CCM=E2=80=9D abbreviates = =E2=80=9CComputer Modern=E2=80=9D. =2E.. The following fonts are not members of a family. CW CM Typewriter Text (cmtt10) CWI CM Italic Typewriter Text (cmitt10) TeX DVI's Computer Modern Typewriter faces don't offer a full "family" of four styles as its ordinary and sans serif faces do. The choice of "CW" and "CWI" as abbreviations for these is unfortunate. It apes a convention occasionally used in AT&T troff, specifically in Unix System III (1980) where some special contrivances were made for typesetting "constant-width" (thus "CW") faces. Unix hackers are enamored of their terse identifiers, and never repent of the confusing ambiguity they introduce in pursuit of them. And if such practice shrouds their development activity in mystique, so much the better, it is thought. If I were an even more aggressive reformer than I am, I'd revise all of the font names used by grodvi to match those used by Knuth for them, but in caps and chopping off the "10". This would acquire the virtue of _familiarity_ for experienced TeX users. (I'd retain "T" and "H" family remappings to maintain groff's attempt at typeface ecumenicism and document portability, of course. And people trying to select "CB" and "CBI" would be warned as they should be, since those faces would be unavailable.) > which looks more suitable. But CR is not listed in "safe" subset > (man 7 man) The Linux man-pages man(7) document was stale or inaccurate in this respect. However, man pages generally should not attempt to access specific fonts by name anyway. They should use the macro facilities afforded by the _man_ package to style their text. groff_man_style(7): Portability =2E.. The two major features that control formatting in the roff language are requests and escape sequences. Since the man macros are implemented in terms of these, one can, in principle, supplement the functionality of man with these lower=E2=80=90level elements where necessary. However, use of roff requests (apart from the empty request =E2=80=9C.= =E2=80=9D) risks poor rendering when your page is processed by non=E2=80=90roff formatters that attempt to interpret page sources. (Historically, this was commonly attempted for HTML conversion.) Requests may make assumptions that do not hold in an HTML environment. Many of these programs don=E2=80=99t interpret the full roff language (let alo= ne extensions): they may be incapable of handling numeric expressions, control structures, or register, string, and macro definitions. Such limitations can lead to portions of a document being presented incomprehensibly or omitted altogether. =2E.. Exercise restraint with escape sequences as with requests. > Also, neither CW nor CR work with html output: >=20 > with \fC >=20 > .TH "" "1"=20 > .PP > \fBThis is test\fP=20 > \fCcode a+b\fP here a+b. >=20 > yields (groff -Thtml test.man) >=20 > <p><b>This is test</b> <tt>code a+b</tt> here a+b.</p> >=20 > Note <tt> tag. > > but with \f[CW] >=20 > .TH "" "1"=20 > .PP > \fBThis is test\fP=20 > \f[CW]code a+b\fP here a+b. >=20 > <p><b>This is test</b> code a+b here a+b.</p> >=20 > No special markup is applied to the code. >=20 > Same for \f[CR]. The "html" output device has its own significant pile of problems and I won't make this long mail even longer by going into them here. I hope to improve the situation in the coming years. > What I did for the mu4e man-pages was to patch them to alias font C to > B: >=20 > .ftr C B Can you share a link to the mu4e man pages for me? I'd like to have a look at them so I can make suggestions. If you'd be open to them. As a rule, I think doing the foregoing in a man page document should be unnecessary. > My initial assumption when I first looked into this is that the font > to use would be `CR`, not `CW`. Doing this with `CR` does seem to > work: >=20 > $ cat /space/azazel/tmp/test.man=20 > .ftr C CR >=20 > .TH "" "1" > .PP > \fBThis is test\fP > \fCcode a+b\fP here a+b. > $ groff -Thtml /space/azazel/tmp/test.man | tail -5 | head -2 > <p style=3D"margin-top: 1em"><b>This is test</b> <tt>code > a+b</tt> here a+b.</p> >=20 > However, as you observe, `\f[CR]` doesn't (nor does `\f(CR`). I note > that groff's HTML support is stated in the grohtml(1) man-page to be > in beta. Haven't checked the source to determine whether that is > what's going on here. It's a mess. :( https://savannah.gnu.org/bugs/index.php?61915 That's the tip of a large iceberg. > In any case, my understanding from reading the conversation in the > Debian bug-report is that this issue affects multiple roff generators > in Debian. Therefore, it probably makes sense to consult within > Debian before asking the maintainers of those generators to make > changes. I need to go over that conversation again and think about > this more. Please consider me, and the groff mailing list, a resource. Regards, Branden --m62nbg7v6n44c7z7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmdjBF8ACgkQ0Z6cfXEm bc70Rg/+NtkTuhQAh8nS66r7nl8M4YgzQezsNIMEdT/jBs7c9wxrU2RGH5NRptAo Uo6sThp0OWuRJQJFOYg5ekRQsQrX6CaghDDqEEc57snEFccxaJftH0XHH7tMxSTF oOFV9OTD/1bzr1wXwkb6ujt/BUxWqiI4k6EpAxoXpMTxekl6pURgfuZU242I9qUs rFND9cBSgvcub2QR6uRZwWrrHyGq6QL7o2Jdn1U4CakYHX1J98XquGgQJ4/I+8vg DMf5ki2kl7LA6JerG9Y4nmfADxEUC3kU5a6b1fYWnpbAAb8nJl+ZJ33CBko6kJ+w IVcAEOrSpixUpKTwLMdnHAmWmFq1smPPY03gS3oTQzsuXQkePmwaqbMn5q2Xs6gc iZhUB38iz2XQrUSOLts2IK+CHLP/HD4OGnTuD1QO5KiYTeTOz/1Aw7lRpkagntiv IC13MMXSYFBn4C11E07lxJm2xtxcA30fsTtVtGFiSzaFjFuA3OWi6x4jOLObo75a 8TBb4voZHxpd84Pj2iZj2Gs5k5Sr1uFbpAsRa9W2Placf36oMK4990X62B0i1qgo SX7vXd8M5bRDJ7JcuVjiKrkAl6jO9jyZ5sXZcQM75cQS9uN5Xklffe83ilI84hf3 ZVc4yBBJpB+ySbu7r4vXb89tsjBtMcHUe9TsKrwZyiJeYhIuaXc= =V/us -----END PGP SIGNATURE----- --m62nbg7v6n44c7z7--