pixels as unit type

Previous topic - Next topic

Brrt

It would be great to have the option to select pixels as the documents main unit type (both measurements and fonts), turning Scribus in an alternative for Indesign and Fireworks when it comes to static wireframing and other web-related design tasks.

Nermander

IMO it does not make sense to use pixels as a unit because a pixel has no physical dimension.

In Scribus you primarily work with vectors (fonts and native vector elements), pixels are only used in image frames (where the frame has a physical dimension so the pixels can be scaled).


Brrt

I understand that in many traditional fields this request would not make sense. Working for print products I never encountered these problems, but now that I'm designing for digital products, I find it very difficult to define a 1px wide line that will actual be sharp on all devices (that show pixels).

If the end result must be 1:1 in pixels, there is now logic in working in mm, inches or anything other than pixels. The size of elements on the page must be designed and measured in the same unit they will be build in, since there is not going to be any transition to paper. Designing a 400px wide element on screen (in Scribus) as a 40mm element only leads to continuous translation between unit types.
Pixel perfect design is only possible in pixels.

Nermander

I think Scribus is not the tool you should use, try using for example Gimp instead.

Brrt

#4
Unfortunately GIMP is not suitable for this type of work, because it is not vector based, but pixel based. Using pixels as a measurement unit is very different from pixelbased work. For the moment I'll have to stick to indesign.

maybe this article will shine some light on the type of work involved:
http://blog.tawhidkhan.com/replace-adobe-fireworks-uiux-design-tools-comparison/

Nermander

Quote from: Brrt on January 21, 2014, 01:40:05 PM
Designing a 400px wide element on screen (in Scribus) as a 40mm element only leads to continuous translation between unit types.

Why don't you design the 400 px wide element as a 400 mm element? Then 1 mm = 1 pixel, no conversion needed, line width of 1 mm = 1 pixel etc.

Brrt

That is the current workaround. However, viewing the result on 1px = 1px is very difficult with this method. It involves scaling a resulting pdf of 1000mm wide to exactly 1000px on a screen. As you can imagine, not ideal for communicating. If pixels would be available as a unit type, 100% viewing of the pdf would always produce the correct result.

Nermander

The base unit in the PDF format is postscript points. So, when exporting to PDF, how many points would a pixel be?

Brrt

Currently, if pixels is the unit type, Indesign generates a pdf that on 100% will be 1px = 1px.

Nermander

Well, examine that PDF then and answer the question, then the devs might implement it.

As far as I know all measurements in a PDF are postscript points.

SuburbanWorrier

I support the OP on this.
For me the Gimp doesn't have the text handling capability to be a viable alternative (nor does Inkscape).  I need to create a composite image containing vectors, bitmaps and text so, despite the absence of pixels as a measurement unit, Scribus is the obvious choice.
In fact I've used Scribus before and have opened up a previous .sla only to be completely stumped as to how I worked out the document size in the first place!

My  €0.02

Nermander

Well, the main question still remains: How many points shall a pixel be? Because in i PDF all measurements are in postscript points.


And I'd say that for the situation you describe Scribus is not the obvious choice, I'd say Inkscape might be a better candidate.

SuburbanWorrier

In this use-case I'm not interested in pdf output.
I understand why you're hung up about it but as the OP mentions Fireworks then he, like myself, is likely to be looking at bitmap output.  Hence really needing to be able to define 1pixel correctly - else hairlines get (randomly) antialiased.

I use Inkscape pretty much every day and the text control is nowhere near as refined as Scribus (or Fireworks from what I remember of it).

I do understand that Scribus = DTP but it's soooo close to being an all round digital design tool as well.  It really doesn't make sense for me to work on print based designs and then start all over elsewhere.

For the task that spurred my earlier post I set the document units to points, worked as if they were (final output) pixels and exported pages as images at 100% (72dpi)

ATB

GarryP

I'm reading this and getting very confused.

Brrt (and SuburbanWorrier, to some extent)

I really don't see the need for such precision.

I'm assuming that you will have no control over what size/resolution/density - Retina displays anyone? - the screen will have when the document is reviewed so it will have to be resized in a way that you have little-to-no control over how it looks anyway. So why bother trying to be so precise when you have no way of knowing how the document will be seen?

Isn't it better to concentrate on getting it looking good as opposed to getting it looking precise? Even bitmaps are scaled on different screens so their pixels won't be guaranteed to be on pixel boundaries - and therefore may not be drawn "properly" - so you can't assume anything.

SuburbanWorrier (and Brrt, to some extent)

I'm not really sure what you want.

For web prototyping I think you might be better off using something like invision http://www.invisionapp.com/ (many alternatives are available but I just happen to know that this one is free for messing around with).

If you're prototyping in Scribus (or whatever else), and then have to translate that design to the web, you're going to have to re-design anyway. So why not use a prototyping tool that allows you to use the prototype in the finished design?

You say it makes no sense to work on print based designs but that's exactly what you're doing when working in Scribus. You have to translate the text/image frames etc. into <div>s and whatnot anyway so why not use something where you don't have to do the translation? And then there's the whole responsive design thing to take into account. It really makes no sense - to me, at least - to be designing a static page in Scribus for later use on the web where everything is different.

It might be good for quick mock-ups, but if you're being so precise in a mock-up then you may be putting too much work into the wrong things. Work on the overall "feel" in the mock-up then be precise in your CSS later.

Both

Without knowing exactly what you're each trying to do I can't really give more specific advice but I think you could be "overthinking" this a bit.

Scribus is a (printed) page design tool. It's not a free replacement for InDesign or Quark (or anything else). It's its own thing and it does what it does very well. It would be nice if it could do more but I think you're asking for a little too much from it.

Apologies if I sound overly argumentative - that's really not my intention - but I'm frankly baffled by the requirements given.

SuburbanWorrier

Lol

You don't come across as overly argumentative (anyway, what's wrong with an argument? ;-) )

For me, I needed to update the profile headers for all the social media platforms we use.  As I've already defined a bunch of print ready artworks in our house style using Scribus I think it reasonable that I continue to use the tool for what will be jpeg or png outputs.

As far as accuracy is concerned I know that Facebook needs an 851x315px image so what size should my document be?

So, for me it's not prototyping, or web design as such but a matter of production workflow. You've misunderstood my comment about print design.  The point is that I've already done the majority of the (design) work, using Scribus, for print outcomes so what is my motivation for choosing another tool and effectively starting from scratch?

I think the real tension here is that you (and Nermander) are maybe concentrating on the tool and I'm interested in the outcome.  You can buy a dedicated tool to lift paint can lids but we all use the screwdriver that's sat in our back pockets.

And I agree, Scribus is Scribus and long may it reign. The gap in the market, which no program has come close to filling , has been left by the effective withdrawal of Fireworks - and I'm 100% Linux here at work anyway.

ATB