Hi Volker,
thank you for your speedy reply, and also for this fine software!
ad 1)
I have a directory "mwlibfonts" in my $HOME, in it are links to the system
fonts as well as a single file "trebuc.ttf" for the "Trebuchet" font I'd
like to use.
In "fontconfig.py":
fonts = [
{'name' : 'Trebuchet', 'code_points' : ['Basic Latin'], 'xl_scripts' :
['Latin'], 'file_names' : ['trebuc.ttf'],}, ...
and in "pdfstyles.py" the variables "default_font" and "serif_font" are set
to 'Trebuchet'.
In a test document, most of the text is rendered in the standard serif font,
only the "References" section uses the Trebuchet font for its heading and
the external links. (Btw., people here prefer in-place external links to
putting the links in the "References" section, specifically for
email-addresses; is there an easy way to change this behaviour?)
ad 2)
Sorry, this was a misconception on my part about what is done by mwlib vs.
what mediawiki does. However, we are interested in ways to provide more
control over the pdf-creating process to the authors, who are not
necessarily technical people and would like to have some simple means to
e.g. "theme" the pdf output.
I am currently trying to wrap my head around all of this ...
ad 3)
I added the two lines from the diff locally, but i didn't work ... does this
depend on the current git versions of mwlib and mwlib.rl?
Regards,
Stefan
2011/6/30 Volker Haas <[email protected]>
> Hi Stefan,
>
>
> On 06/29/2011 12:45 PM, Stefan Birkholz wrote:
>
>> Hi all,
>>
>> we use mediawiki + mwlib + mwlib.rl for our documentation; we have two
>> documentation servers running mwlib-0.12.13 + mwlib.rl-0.12.5 (on the
>> production system) and mwlib-0.12.14 + mwlib.rl-0.12.8 (on the testing
>> system).
>>
>> A couple of questions:
>>
>> - font-selection does not seem to work: defining two variables
>> "default_font" and "special_font" in pdfstyles.py and customconfig.py
>> has no visible effect, although the designated font is embedded in the
>> resulting .pdf file.Furthermore, even overwriting the
>> "sans_font"/"serif_font" variables in both files also does not seem to
>> have any effect, the resulting .pdf still embeds "AAAAAA+FreeSerif"
>> and "AAAAAA+FreeSerifBold". How can I get other fonts to be used per
>> default for text?
>>
> You need to do 2 things to change fonts:
>
> Change default_font and at least serif_font in pdfstyles.py as you
> apparently did.
>
> Furthermore you need to register that font to a unicode-range(block).
> This is done in fontconfig.py
>
> I just tested that it works with the following example:
>
> fonts = [
> {'name': 'Ubuntu',
> 'code_points': ['Basic Latin',],
> 'xl_scripts': ['Latin'],
> 'file_names': ['ubuntu-font-family/Ubuntu-R.**ttf',
> 'ubuntu-font-family/Ubuntu-B.**ttf', 'ubuntu-font-family/Ubuntu-RI.**ttf',
> 'ubuntu-font-family/Ubuntu-BI.**ttf'],
> },
> ...
> ]
>
> Check the "font_paths" variable to get a correct full path (you probably
> want to create the mwlibfonts dir in your home and then place symlinks to
> you system fonts there)
>
>
> - it would be nice to be able to use<para>...</para> commands in an
>> wiki-article to have somewhat more control over the creation of the
>> pdf if those could be escaped in mwlib and sent to platypus;
>> apparently, here the '<' and'>' chars get replaced by mwlib, however,
>> this does not happen for e.g.<br> tags. Is this possible?
>>
> No, this is not possible. What are you trying to do? There is already
> support for quite a bit of styling via css. I don't want to allow using a
> special para tag since that would be rendered as "<para>" in the browser.
> Every styling command should be done using css styles or classes (css
> classes only have an effect if they are defined in a css_map variable as
> "specified" in customnodetransformer.py).
>
> But again: what are you trying to achieve? Maybe I can add support for
> that, alternatively I would gladly accept a patch ;)
>
>
> - on the production system, {{command|...}} and {{filename|...}} are
>> displayed similarly to<tt>...</tt> in the online-article, and when
>> exported to pdf they also employ a monospaced font, but on the testing
>> system these to tags are apparently translated to<code>...</code>
>> tags - and these won't get a monospace font in a pdf created on the
>> testing system! (Whereas something in<tt>...</tt> tags will.) I
>> suspect this might also be due to differing mediawiki-versions, but
>> shouldn't the text between<code>...</code> tags use a monospace font
>> in the pdf?
>>
>
> Thanks for reporting - this was a bug. I fixed the problem in the git repo
> (http://code.pediapress.com/**git/mwlib<http://code.pediapress.com/git/mwlib>
> )
>
> Regards,
> Volker
>
> --
> volker haas brainbot technologies ag
> fon +49 6131 2116394 boppstraße 64
> fax +49 6131 2116392 55118 mainz
> [email protected] http://www.brainbot.com/
>
> --
> You received this message because you are subscribed to the Google Groups
> "mwlib" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to mwlib+unsubscribe@**
> googlegroups.com <mwlib%[email protected]>.
> For more options, visit this group at http://groups.google.com/**
> group/mwlib?hl=en <http://groups.google.com/group/mwlib?hl=en>.
>
>
--
You received this message because you are subscribed to the Google Groups
"mwlib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mwlib?hl=en.
