From owner-freebsd-doc@FreeBSD.ORG Tue Jul 23 22:58:52 2013 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97E53961 for ; Tue, 23 Jul 2013 22:58:52 +0000 (UTC) (envelope-from gabor.kovesdan@gmail.com) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F09B2B42 for ; Tue, 23 Jul 2013 22:58:52 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id e49so4745097eek.6 for ; Tue, 23 Jul 2013 15:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Yl3+N+dNGJj1TAtFBphYxKeWBQv/r81zGNd9wPkrkV0=; b=R9rV5LGNjaQ2tkaxLL9Q0hO8I0G8LUMxU8fyFW0P4K+7ULFZJj28F5DB4OeVm5TaUx iVFMjVLxUqOnZHdlffEL+Aqu2eUy+KJ2P+kw4VscgaVsZeIMmawT7nRDEBpBWd1Hcw5w P83hNAVn/dH6V4j0dWiMzjPewmP7dBlnuqRvQxXUGxWAaiUsRjCk3NZ6NzIZ+KZcUdNU gQM0ZuyEUmPPsDS4GTOZzVfRh6jv89MkzILWHXlccn9FlVy9b7AWtM8ugQCXlN/B1gV7 GeTnN+771K1940Ux0CaS3EI19IhB0lnyK3QQbh0xPjuiZ3VUW3XdOIR5gv0QjSaPg6NV wD9A== X-Received: by 10.15.41.196 with SMTP id s44mr34729827eev.138.1374620330410; Tue, 23 Jul 2013 15:58:50 -0700 (PDT) Received: from [192.168.1.117] (catv-80-99-23-232.catv.broadband.hu. [80.99.23.232]) by mx.google.com with ESMTPSA id l42sm61754007eeo.14.2013.07.23.15.58.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 15:58:49 -0700 (PDT) Message-ID: <51EF0A9D.8060109@FreeBSD.org> Date: Wed, 24 Jul 2013 00:58:37 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0a2 MIME-Version: 1.0 To: Warren Block Subject: Re: CFR: documentation rendered in PDF with FOP References: <51EE8750.7040208@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FBSD Doc project X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:58:52 -0000 On 2013.07.23. 23:11, Warren Block wrote: > > Thanks for your work on this! > > In a quick look, I did not notice any obvious problems. What are the > quality problems with dblatex? - Customization is more complicated. - Overall outlook just doesn't look so nice. That may be improved by customization but that's not so trivial. - It doesn't support programlistings in lists and several documents still fail because of this. - Somehow it doesn't properly wrap non-Latin text: http://kovesdan.org/files/tex-ja.pdf Maybe it is trivial to fix, I just don't know how CJK text is handled in TeX. But I don't understand why something so trivial doesn't just work out of the box. > There is something weird about bulleted lists and sub-lists, starting > on page 35 of the PDF Handbook (page 7-9 of the content). Some > entries in the first list are blank, the ones in the second list have > an extra linefeed after the bullet. It is a known issue and is actually the result of misplaced indexterms, not a bug in the rendering. I've already fixed some of them in the English docs but translations still has to be fixed and there may be slightly different cases, which I haven't caught yet. We should document in fdp-primer that indexterms should be put right inside of the text after the referred word. Not between paragraphs, not into , not into but right inside after the referred word without leaving a single a space. If they are not in , it can cuase such problems. And if you put a space before the indexterm, there may be a page break and you get a wrong page number in the index. But the probability of this latter is very low, the former thing is more important. > The line-wrap characters are very welcome! They still need some tuning > (see PDF page 26). Or maybe that's in the source XML, but it's good > to see a start on that! Yes, I've also noticed that that page is quite weird. The line-wrap part should be easy to fix, we just have to add the comma as a possible wrapping character. It is stranger why the text overflows instead of causing a page break. The good thing is that the output of the renderer is very clean and we can clearly see which pages have overflows. Gabor