desired .Bk semantics?

desired .Bk semantics?

[Ingo Schwarze]

Hi,

after much headbanging while trying to understand tmac files,
i guess i finally figured out what .Bk -words is supposed to do.
It seems it has nothing to do with macros, but simply with -
lines in the input file!  My impression is that .Bk -words
avoids line breaks inside the output generated from each input
line.  Perhaps that's why it is called -words (as opposed to -line).
Duh.

Before i start implementing that - it will be a bit tricky,
because Bk will be the first macro having explicit BLOCKs and
implicit BODYs - i should like to get feedback whether you

 1) agree with my analysis
 2) agree that is sane semantics

As far as i can see, it does seem at least semi-sane and would
probably fix the remaining .Bk issues in our tree.

But i don't want to implement it and then have everybody yell at
me what a bad idea it is.  =:c)

Yours,
  Ingo


P.S.
Running the following test file through groff 1.20.1 (NEW groff)
seems to support my analysis.  Running it through our old groff
just shows how buggy our old groff is.  Oh well...


.Dd July 2, 2010
.Dt BK-BREAK 1
.Os
.Sh NAME
.Nm Bk-break
.Nd handling of word keeps
.Sh SYNOPSIS
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo
.Oo a Oc
.Oo b Oc
.Oc
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo
.Oo a Oc Oo b Oc
.Oc
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo a b
.Oc
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo a
b
.Oc
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo a Oc b
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo a Oc
b
.Ek
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: desired .Bk semantics?

[Jason McIntyre]

On Sat, Jul 03, 2010 at 01:43:20AM +0200, Ingo Schwarze wrote:
> Hi,
> 
> after much headbanging while trying to understand tmac files,
> i guess i finally figured out what .Bk -words is supposed to do.
> It seems it has nothing to do with macros, but simply with -
> lines in the input file!  My impression is that .Bk -words
> avoids line breaks inside the output generated from each input
> line.  Perhaps that's why it is called -words (as opposed to -line).
> Duh.
> 

according to mdoc.samples(7) it is useful for "preventing line breaks in
the middle of options", and that is how i've always used it. i just
realised that the same piece of text notes that the effect was once
achieved using the Op macro.

so my understanding is it has nothing to do with keeping "words". but
god knows.

jmc
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: desired .Bk semantics?

[Kristaps Dzonsons]

>> after much headbanging while trying to understand tmac files,
>> i guess i finally figured out what .Bk -words is supposed to do.
>> It seems it has nothing to do with macros, but simply with -
>> lines in the input file!  My impression is that .Bk -words
>> avoids line breaks inside the output generated from each input
>> line.  Perhaps that's why it is called -words (as opposed to -line).
>> Duh.
>>
> 
> according to mdoc.samples(7) it is useful for "preventing line breaks in
> the middle of options", and that is how i've always used it. i just
> realised that the same piece of text notes that the effect was once
> achieved using the Op macro.

Ingo, if you and Jason think this is worth the effort (and correct), 
then by all means.  HOWEVER.  `Bk' is a turd that should be flushed: it 
gives the author unnecessary control over output.  This is wrong.

What we should do is ignore `Bk' and follow an easy algorithm for 
SYNOPSIS mode regarding breaking between children.  This, I think, is 
easier for us and manual writers alike.

Is `Bk' used often outside of this where .nr nS 1 is otherwise 
unacceptable (like those OpenBSD .9 manuals)?

Kristaps
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: desired .Bk semantics?

[Jason McIntyre]

On Sat, Jul 03, 2010 at 02:27:21PM +0200, Kristaps Dzonsons wrote:
> >>after much headbanging while trying to understand tmac files,
> >>i guess i finally figured out what .Bk -words is supposed to do.
> >>It seems it has nothing to do with macros, but simply with -
> >>lines in the input file!  My impression is that .Bk -words
> >>avoids line breaks inside the output generated from each input
> >>line.  Perhaps that's why it is called -words (as opposed to -line).
> >>Duh.
> >>
> >
> >according to mdoc.samples(7) it is useful for "preventing line breaks in
> >the middle of options", and that is how i've always used it. i just
> >realised that the same piece of text notes that the effect was once
> >achieved using the Op macro.
> 
> Ingo, if you and Jason think this is worth the effort (and correct), 
> then by all means.  HOWEVER.  `Bk' is a turd that should be flushed: it 
> gives the author unnecessary control over output.  This is wrong.
> 

i agree (with kristaps).

> What we should do is ignore `Bk' and follow an easy algorithm for 
> SYNOPSIS mode regarding breaking between children.  This, I think, is 
> easier for us and manual writers alike.
> 

absolutely! SYNOPSIS is a hugely important part of the page - it's the
first thing people see. and we don;t want it looking like shit. and we
don;t want man page writers fannying around trying to make it look ok.
it should just work sanely.

> Is `Bk' used often outside of this where .nr nS 1 is otherwise 
> unacceptable (like those OpenBSD .9 manuals)?
> 

it is a synopsis-only thing. obviously we sometimes have mini synopses
outside the main SYNOPSIS section. in those cases we could currently
find Bk. i'm not aware of any other places it would normally occur.

jmc
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: desired .Bk semantics?

[Kristaps Dzonsons]

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]

> i agree (with kristaps).
> 
>> What we should do is ignore `Bk' and follow an easy algorithm for 
>> SYNOPSIS mode regarding breaking between children.  This, I think, is 
>> easier for us and manual writers alike.
>>
> 
> absolutely! SYNOPSIS is a hugely important part of the page - it's the
> first thing people see. and we don;t want it looking like shit. and we
> don;t want man page writers fannying around trying to make it look ok.
> it should just work sanely.
> 
>> Is `Bk' used often outside of this where .nr nS 1 is otherwise 
>> unacceptable (like those OpenBSD .9 manuals)?
>>
> 
> it is a synopsis-only thing. obviously we sometimes have mini synopses
> outside the main SYNOPSIS section. in those cases we could currently
> find Bk. i'm not aware of any other places it would normally occur.

Ingo and Jason,

I propose the following.  I've enclosed a patch that demonstrates this.

First, I disabled `Bk' completely.

Second, when `Op' or `Oo' is encountered with MDOC_SYNPRETTY (i.e., in a
SYNOPSIS section or with ".nr nS 1"), spaces are made non-breaking.

Example (mandoc -Owidth=70 ssh.1):

SYNOPSIS
     ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address]
         [-c cipher_spec] [-D [bind_address:]port] [-e escape_char]
         [-F configfile] [-I pkcs11] [-i identity_file]
         [-L [bind_address:]port:host:hostport] [-l login_name]
         [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
         [-R [bind_address:]port:host:hostport] [-S ctl_path]
         [-W host:port] [-w local_tun[:remote_tun]] [user@]hostname
         [command]

Note: this is after removing the escaped spaces that the manual author
had added here and there.

Example (mandoc -Owidth=70 spamd.8):
     spamd [-45bdv] [-B maxblack] [-c maxcon]
           [-G passtime:greyexp:whiteexp] [-h hostname] [-l address]
           [-M address] [-n name] [-p port] [-S secs] [-s secs]
           [-w window] [-Y synctarget] [-y synclisten]

This removes the `Bk' mess and gives a nice, regular algorithm for
formatting in MDOC_SYNPRETTY.

It can/will be trivially extended to the function macros, Fa and Fn and
family.

Thoughts?

Kristaps

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 2026 bytes --]

Index: mdoc_term.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/mdoc_term.c,v
retrieving revision 1.168
diff -u -r1.168 mdoc_term.c
--- mdoc_term.c	2 Jul 2010 15:03:14 -0000	1.168
+++ mdoc_term.c	3 Jul 2010 16:26:03 -0000
@@ -72,7 +72,6 @@
 static	void	  termp_an_post(DECL_ARGS);
 static	void	  termp_aq_post(DECL_ARGS);
 static	void	  termp_bd_post(DECL_ARGS);
-static	void	  termp_bk_post(DECL_ARGS);
 static	void	  termp_bl_post(DECL_ARGS);
 static	void	  termp_bq_post(DECL_ARGS);
 static	void	  termp_brq_post(DECL_ARGS);
@@ -98,7 +97,6 @@
 static	int	  termp_aq_pre(DECL_ARGS);
 static	int	  termp_bd_pre(DECL_ARGS);
 static	int	  termp_bf_pre(DECL_ARGS);
-static	int	  termp_bk_pre(DECL_ARGS);
 static	int	  termp_bl_pre(DECL_ARGS);
 static	int	  termp_bold_pre(DECL_ARGS);
 static	int	  termp_bq_pre(DECL_ARGS);
@@ -238,7 +236,7 @@
 	{ NULL, NULL }, /* Fc */ 
 	{ termp_op_pre, termp_op_post }, /* Oo */
 	{ NULL, NULL }, /* Oc */
-	{ termp_bk_pre, termp_bk_post }, /* Bk */
+	{ NULL, NULL }, /* Bk */
 	{ NULL, NULL }, /* Ek */
 	{ termp_bt_pre, NULL }, /* Bt */
 	{ NULL, NULL }, /* Hf */
@@ -1279,6 +1277,8 @@
 
 	if (MDOC_BODY != n->type) 
 		return;
+	if (MDOC_SYNPRETTY & n->flags)
+		p->flags &= ~TERMP_KEEP;
 	p->flags |= TERMP_NOSPACE;
 	term_word(p, "\\(rB");
 }
@@ -1460,6 +1460,8 @@
 	case (MDOC_BODY):
 		term_word(p, "\\(lB");
 		p->flags |= TERMP_NOSPACE;
+		if (MDOC_SYNPRETTY & n->flags)
+			p->flags |= TERMP_KEEP;
 		break;
 	default:
 		break;
@@ -2138,37 +2140,6 @@
 	return(0);
 }
 
-
-/* ARGSUSED */
-static int
-termp_bk_pre(DECL_ARGS)
-{
-
-	switch (n->type) {
-	case (MDOC_BLOCK):
-		break;
-	case (MDOC_HEAD):
-		return(0);
-	case (MDOC_BODY):
-		p->flags |= TERMP_PREKEEP;
-		break;
-	default:
-		abort();
-		/* NOTREACHED */
-	}
-
-	return(1);
-}
-
-
-/* ARGSUSED */
-static void
-termp_bk_post(DECL_ARGS)
-{
-
-	if (MDOC_BODY == n->type)
-		p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
-}
 
 /* ARGSUSED */
 static int

Re: desired .Bk semantics?

[Jason McIntyre]

On Sat, Jul 03, 2010 at 06:24:47PM +0200, Kristaps Dzonsons wrote:
> 
> Ingo and Jason,
> 
> I propose the following.  I've enclosed a patch that demonstrates this.
> 
> First, I disabled `Bk' completely.
> 
> Second, when `Op' or `Oo' is encountered with MDOC_SYNPRETTY (i.e., in a
> SYNOPSIS section or with ".nr nS 1"), spaces are made non-breaking.
> 
> Example (mandoc -Owidth=70 ssh.1):
> 
> SYNOPSIS
>      ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address]
>          [-c cipher_spec] [-D [bind_address:]port] [-e escape_char]
>          [-F configfile] [-I pkcs11] [-i identity_file]
>          [-L [bind_address:]port:host:hostport] [-l login_name]
>          [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
>          [-R [bind_address:]port:host:hostport] [-S ctl_path]
>          [-W host:port] [-w local_tun[:remote_tun]] [user@]hostname
>          [command]
> 
> Note: this is after removing the escaped spaces that the manual author
> had added here and there.
> 
> Example (mandoc -Owidth=70 spamd.8):
>      spamd [-45bdv] [-B maxblack] [-c maxcon]
>            [-G passtime:greyexp:whiteexp] [-h hostname] [-l address]
>            [-M address] [-n name] [-p port] [-S secs] [-s secs]
>            [-w window] [-Y synctarget] [-y synclisten]
> 
> This removes the `Bk' mess and gives a nice, regular algorithm for
> formatting in MDOC_SYNPRETTY.
> 
> It can/will be trivially extended to the function macros, Fa and Fn and
> family.
> 
> Thoughts?
> 

spiffing!

i wonder though about disabling Bk...do you mean it just ignores it, or
that the current Bk/Ek in files will cause a problem? i'm not averse to
removing them from pages, but i need to think about our pages being
formatted on another system. for example, for ssh.1 to have a fighting
chance on a non-mandoc system.

i don;t know how practical that is though. i haven;t thought very far
ahead about this. keep the keeps (er) or remove them...

jmc
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: desired .Bk semantics? [UPDATED PATCH]

[Kristaps Dzonsons]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

> spiffing!
> 
> i wonder though about disabling Bk...do you mean it just ignores it, or
> that the current Bk/Ek in files will cause a problem? i'm not averse to
> removing them from pages, but i need to think about our pages being
> formatted on another system. for example, for ssh.1 to have a fighting
> chance on a non-mandoc system.
> 
> i don;t know how practical that is though. i haven;t thought very far
> ahead about this. keep the keeps (er) or remove them...

Here's an updated version of the patch that also addresses `Fn' and `Fa'.

It also correctly uses TERMP_PREKEEP instead of TERMP_KEEP, and dips
into encode() to transcode quoted whitespace into ASCII_NBRSP (such as
the case of `Fa "foo bar"').

Ingo, what do you think?

Kristaps

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 4878 bytes --]

? .mdoc.3.swp
? config.h
? config.log
? foo.1
? foo.1.html
? foo.3
? foo.7
? foo.html
? mandoc
? patch.txt
? relayd.8
? relayd.8.html
? spamd.8
? ssh.1
? ssh.1.html
? regress/output
Index: mdoc_term.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/mdoc_term.c,v
retrieving revision 1.169
diff -u -r1.169 mdoc_term.c
--- mdoc_term.c	3 Jul 2010 17:17:15 -0000	1.169
+++ mdoc_term.c	3 Jul 2010 17:25:45 -0000
@@ -72,14 +72,13 @@
 static	void	  termp_an_post(DECL_ARGS);
 static	void	  termp_aq_post(DECL_ARGS);
 static	void	  termp_bd_post(DECL_ARGS);
-static	void	  termp_bk_post(DECL_ARGS);
 static	void	  termp_bl_post(DECL_ARGS);
 static	void	  termp_bq_post(DECL_ARGS);
 static	void	  termp_brq_post(DECL_ARGS);
 static	void	  termp_bx_post(DECL_ARGS);
 static	void	  termp_d1_post(DECL_ARGS);
 static	void	  termp_dq_post(DECL_ARGS);
-static	int	  termp_fd_pre(DECL_ARGS);
+static	void	  termp_fa_post(DECL_ARGS);
 static	void	  termp_fo_post(DECL_ARGS);
 static	void	  termp_in_post(DECL_ARGS);
 static	void	  termp_it_post(DECL_ARGS);
@@ -98,7 +97,6 @@
 static	int	  termp_aq_pre(DECL_ARGS);
 static	int	  termp_bd_pre(DECL_ARGS);
 static	int	  termp_bf_pre(DECL_ARGS);
-static	int	  termp_bk_pre(DECL_ARGS);
 static	int	  termp_bl_pre(DECL_ARGS);
 static	int	  termp_bold_pre(DECL_ARGS);
 static	int	  termp_bq_pre(DECL_ARGS);
@@ -109,6 +107,7 @@
 static	int	  termp_dq_pre(DECL_ARGS);
 static	int	  termp_ex_pre(DECL_ARGS);
 static	int	  termp_fa_pre(DECL_ARGS);
+static	int	  termp_fd_pre(DECL_ARGS);
 static	int	  termp_fl_pre(DECL_ARGS);
 static	int	  termp_fn_pre(DECL_ARGS);
 static	int	  termp_fo_pre(DECL_ARGS);
@@ -161,10 +160,10 @@
 	{ NULL, NULL }, /* Er */ 
 	{ NULL, NULL }, /* Ev */ 
 	{ termp_ex_pre, NULL }, /* Ex */
-	{ termp_fa_pre, NULL }, /* Fa */ 
+	{ termp_fa_pre, termp_fa_post }, /* Fa */ 
 	{ termp_fd_pre, NULL }, /* Fd */ 
 	{ termp_fl_pre, NULL }, /* Fl */
-	{ termp_fn_pre, NULL }, /* Fn */ 
+	{ termp_fn_pre, termp_fa_post }, /* Fn */ 
 	{ termp_ft_pre, NULL }, /* Ft */ 
 	{ termp_bold_pre, NULL }, /* Ic */ 
 	{ termp_in_pre, termp_in_post }, /* In */ 
@@ -238,7 +237,7 @@
 	{ NULL, NULL }, /* Fc */ 
 	{ termp_op_pre, termp_op_post }, /* Oo */
 	{ NULL, NULL }, /* Oc */
-	{ termp_bk_pre, termp_bk_post }, /* Bk */
+	{ NULL, NULL }, /* Bk */
 	{ NULL, NULL }, /* Ek */
 	{ termp_bt_pre, NULL }, /* Bt */
 	{ NULL, NULL }, /* Hf */
@@ -1279,6 +1278,8 @@
 
 	if (MDOC_BODY != n->type) 
 		return;
+	if (MDOC_SYNPRETTY & n->flags)
+		p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
 	p->flags |= TERMP_NOSPACE;
 	term_word(p, "\\(rB");
 }
@@ -1460,6 +1461,8 @@
 	case (MDOC_BODY):
 		term_word(p, "\\(lB");
 		p->flags |= TERMP_NOSPACE;
+		if (MDOC_SYNPRETTY & n->flags)
+			p->flags |= TERMP_PREKEEP;
 		break;
 	default:
 		break;
@@ -1578,7 +1581,13 @@
 
 	for (nn = n->child->next; nn; nn = nn->next) {
 		term_fontpush(p, TERMFONT_UNDER);
+
+		if (MDOC_SYNPRETTY & n->flags)
+			p->flags |= TERMP_PREKEEP;
 		term_word(p, nn->string);
+		if (MDOC_SYNPRETTY & n->flags)
+			p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
+
 		term_fontpop(p);
 
 		if (nn->next)
@@ -1602,12 +1611,20 @@
 
 	if (n->parent->tok != MDOC_Fo) {
 		term_fontpush(p, TERMFONT_UNDER);
+		if (MDOC_SYNPRETTY & n->flags)
+			p->flags |= TERMP_PREKEEP;
 		return(1);
 	}
 
 	for (nn = n->child; nn; nn = nn->next) {
 		term_fontpush(p, TERMFONT_UNDER);
+
+		if (MDOC_SYNPRETTY & n->flags)
+			p->flags |= TERMP_PREKEEP;
 		term_word(p, nn->string);
+		if (MDOC_SYNPRETTY & n->flags)
+			p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
+
 		term_fontpop(p);
 
 		if (nn->next)
@@ -1622,6 +1639,16 @@
 
 
 /* ARGSUSED */
+static void
+termp_fa_post(DECL_ARGS)
+{
+
+	if (MDOC_SYNPRETTY & n->flags)
+		p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
+}
+
+
+/* ARGSUSED */
 static int
 termp_bd_pre(DECL_ARGS)
 {
@@ -2140,37 +2167,6 @@
 	return(0);
 }
 
-
-/* ARGSUSED */
-static int
-termp_bk_pre(DECL_ARGS)
-{
-
-	switch (n->type) {
-	case (MDOC_BLOCK):
-		break;
-	case (MDOC_HEAD):
-		return(0);
-	case (MDOC_BODY):
-		p->flags |= TERMP_PREKEEP;
-		break;
-	default:
-		abort();
-		/* NOTREACHED */
-	}
-
-	return(1);
-}
-
-
-/* ARGSUSED */
-static void
-termp_bk_post(DECL_ARGS)
-{
-
-	if (MDOC_BODY == n->type)
-		p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
-}
 
 /* ARGSUSED */
 static int
Index: term.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term.c,v
retrieving revision 1.158
diff -u -r1.158 term.c
--- term.c	3 Jul 2010 16:02:12 -0000	1.158
+++ term.c	3 Jul 2010 17:25:45 -0000
@@ -624,7 +624,11 @@
 
 	for (i = 0; i < (int)sz; i++) {
 		if ( ! isgraph((u_char)word[i])) {
-			bufferc(p, word[i]);
+			if (TERMP_KEEP & p->flags && ' ' == word[i])
+				bufferc(p, ASCII_NBRSP);
+			else
+				bufferc(p, word[i]);
+
 			continue;
 		}
 

Re: desired .Bk semantics?

[Ingo Schwarze]

Hi Kristaps,

Kristaps Dzonsons wrote on Sat, Jul 03, 2010 at 06:24:47PM +0200:

> I propose the following.  I've enclosed a patch that demonstrates this.
> First, I disabled `Bk' completely.

I disagree: That is going too far.

Like that, you lose the possibility to keep non-optional arguments
together on the same line.  Consider, e.g.

.Nm cut
.Bk -words
.Fl b Ar list
.Ek
.Op Ar n
.Op Ar
.Nm cut
.Bk -words
.Fl c Ar list
.Ek
.Ar

I admit in this case this is not critical because the keep is near
the beginning of the line, but this is how it should be written,
and such necessities can also arise later on the line,

Thus, do not rip .Bk out completely.
It should be available for the rare cases where is is needed,
and it is a standard mdoc(7) macro we cannot just drop.

> Second, when `Op' or `Oo' is encountered with MDOC_SYNPRETTY (i.e., in a
> SYNOPSIS section or with ".nr nS 1"), spaces are made non-breaking.

I disagree: That is going too far.

Like that, you lose the option to allow breaking in the middle of
an .Op or .Oo group.  Consider, e.g.

.Nm openssl
.Cm gendsa
.Oo
.Fl aes128 |
.Fl aes192 |
.Fl aes256 |
.Fl des |
.Fl des3
.Oc
...

This could get worse when more ciphers are implemented, and ultimately,
it won't fit on one line any more, giving you very ugly output and no way
to fix it.

I don't oppose automatically assuming implied .Bk around .Op and .Oo
tough, as long as they are on one input line, even though troff
historically decided against that.

That's probably the last mail i can send before teardown of the hack
room, and i don't have time to look at your code right now...

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv