<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#003333" bgcolor="#FFFFFF">
    <p><font size="+1"><tt>Issue A: .pdf exporting is like Hong Kong's
          Walled City<br>
        </tt></font></p>
    <p><font size="+1"><tt><font size="+1"><tt><font size="+1"><tt>Some
                  fonts in other languages don't render correctly in
                  pdf. </tt></font></tt></font>I created a repo
          duplicating the problem with multiple pdf export engines:</tt></font></p>
    <p><font size="+1"><tt><a class="moz-txt-link-freetext" href="https://github.com/JesseSteele/pdf-bug">https://github.com/JesseSteele/pdf-bug</a></tt></font></p>
    <p><font size="+1"><tt>Bug report to LibreOffice:</tt></font></p>
    <p><font size="+1"><tt><font size="+1"><tt><a class="moz-txt-link-freetext" href="https://bugs.documentfoundation.org/show_bug.cgi?id=118405">https://bugs.documentfoundation.org/show_bug.cgi?id=118405</a></tt></font></tt></font></p>
    <p><font size="+1"><tt>This bug includes LibreOffice and Calligra,
          but the problem runs deeper. So, I submitted a bug report</tt></font><font
        size="+1"><tt> (above) implicating lowriter, but that won't fix
          everything. There are multiple pdf engines involved, as the
          repo (above) describes. Calligra's pdf exporter seems to be
          doing well with .odt, but not with .doc, which I think we all
          can accept. But, Calligra has other querks.</tt></font></p>
    <p><font size="+1"><tt>On review, I found too many terminal pdf
          engines, loaded with bugs. Could pdf engine cooperation and
          unification just be an idea discussed among developers? Is
          that okay to humbly suggest?<br>
        </tt></font></p>
    <p><font size="+1"><tt>Issue B:<br>
        </tt></font></p>
    <p><font size="+1"><tt>I want to simply highlight/select and
          "context menu > Print..." and entire directory of images. I
          can in W!nd@w$; not pretty, but it works. Even in a Linux
          image viewer app, I'd need to print each image one at a time.</tt></font></p>
    <p><font size="+1"><tt>Summary:<br>
        </tt></font></p>
    <p><font size="+1"><tt>IMHO, any workplace-worthy, publishing-ready
          desktop OS needs these to be central and standard. Can
          lowriter (after it gets fixed) be made to work on exportable
          documents from the GNOME/Xfce context menu? Is there a command
          line tool to "print said images in this directory" with
          count-per-page and black-color options that could be made to
          also work a context menu -initiated GUI... or else an app be
          loaded-ready from the context menu?</tt></font></p>
    <p><font size="+1"><tt>Desktop power users (publishers,
          administrators) need standard PDF and image directory printing
          from the context menu. What about a native script called
          "dirprint" to handle open documents and images TO PRINT or TO
          PDF? I'll even write the BASH script if someone would just
          point me in the right direction and it has a prayer of getting
          into the GNOME/Xfce/KDE/Nautilus/Thunar/Dolphin/etc context
          menu.</tt></font></p>
    <p><font size="+1"><tt>Linux love to all!<br>
        </tt></font></p>
  </body>
</html>