[scribus] designing instructional posters on code/programming -- lots of syntax highlighting

[Gregory Pittman]

On 01/07/2017 07:20 PM, Lars Behrens wrote:
> Am 07.01.2017 um 18:20 schrieb Gregory Pittman:
> 
>> Thanks to Lars, I was able to slave my way through this last night
>> (and slaving it was!), and today made a wiki page outlining the
>> process using a Python script as an example:
>>
>> https://wiki.scribus.net/canvas/Render_frames_and_the_LaTeX_listings_package
> 
> Thanks for your effort in the wiki. I dug through the page and followed
> your examples.
> 
> I was surprised that you had such problems, because here on Unbuntu
> 14.04 with Scribus 1.4.2 the only thing that caused a choke was the
> copyright symbol in your original example, the comment signs don't cause
> any problems here.

Basically I thought that sorting out the issue that came up with
pdflatex outside of Scribus wasn't of great interest to me. Especially
since it's been quite a while since I generated LaTeX files, I had slid
down my prior learning curve, and the documentation that comes with
listings has a paucity of real world concrete examples. I had to modify
the simple examples they showed in order to get them to work.

> 
> There's also no difference in font display here (I declared my tex file
> for import into scribus as "\documentclass[a4paper,11pt]{extarticle}"
> like scribus does internally, but I don't think that this is the real
> source for the difference on your side). I can't zoom
> 
> So there may be a difference either in Scribus' LaTeX handling between
> 1.4.2 and 1.5 or in the LaTeX systems on your and my computer.
> 
> Or I didn't understand the problem :)
> 
>> method is worthwhile. One might even question how much we need render
>> frames given the ability to import PDFs as vectors in 1.5.x
>> versions.
> 
> While I agree that using LaTeX for syntax highlighting in Scribus might
> be not the best or most practicable idea for some or even most users, I
> don't quite agree with your questioning render frames generally.
> 
> I find them extremely helpful when dealing with scientific posters or
> scientific text containing formulas generally and when there are "moving
> targets" among them which may have to be changed eventually. Not having
> to leave Scribus makes the workflow much easier and helps to keep an
> overview.
> 
> I would really miss render frames.

Render frames exist, as I see it, because at the time, importing a PDF
as a vector image didn't exist, so this was the workaround. What I was
envisioning was that, rather than having something like a render frame,
which I guess we have to say creates a PDF, then rasterizes it into a
frame, why not have the same process generate a PDF that we import as a
vector as the final result? Ok, perhaps there is some expediency in
having this rasterization for review, but finally, why not favor quality
over expediency? At this stage of Scribus development, the current
results of render frames looks shabby and nonprofessional. InDesign
would be made a laughingstock if they did something like this - good
enough for hobbyists, not professionals.

Greg