From gpittman at iglou.com  Wed Jul  4 01:56:19 2012
From: gpittman at iglou.com (Gregory Pittman)
Date: Tue, 03 Jul 2012 21:56:19 -0400
Subject: [scribus-dev] keyboard shortcuts listing in Preferences
Message-ID: <4FF3A2C3.5060005@iglou.com>

Not sure if this is a bug per se, but there is a lot of repetition in
the listing of possible keyboard shortcuts in Preferences.

Example:
This block from Soft Hyphen to New Line appears 4 times, twice in the
Insert part of the tree, and twice in the Unicode Characters part of the
tree.

I'm not quite sure why the Unicode Character list needs to be there
anyway, considering that it is mostly/entirely a duplication of what is
in Insert, and the actual unicodes are not listed.

I don't know how this tree is generated, but it must be looking in
different place and therefore duplicating.

Greg


From jlpoole56 at gmail.com  Wed Jul  4 06:19:00 2012
From: jlpoole56 at gmail.com (John L. Poole)
Date: Tue, 03 Jul 2012 23:19:00 -0700
Subject: [scribus-dev] [Cross Post]Version 1.5svn build for Windows?
In-Reply-To: <4FF35B03.60902@gmail.com>
References: <4FF35B03.60902@gmail.com>
Message-ID: <4FF3E054.5050809@gmail.com>

This inquiry, originally posted to the general Scribus list,
should have been posted to this developer's list... I had
forgotten there were two lists.  My apologies for cross posting.

----------------------

I've been tackling building the current high watermark, 1.5svn, on
Windows 7 and have been weighed down on getting the dependencies. For
example, I'm using VC++ 10, not 8.  I'm keeping meticulous notes (which
takes time) against the included build instructions as I go along so
eventually they'll be an Idiot's Guide to Compiling Scribus for Windows
(yes, it's an ironic title).

In the meantime, who has been successfully compiling the HEAD version on
Windows?  Or is the build without regard to keeping it Windows
compile-ready at this time? Is there only one person who makes the
Windows build?

If there are major stumbling blocks that await me, I'd sure like to know
about it.

What would be really nice to have is a current build of Scribus that
follows HEAD -- I'm hoping I might offer that.

John







-------------- next part --------------
A non-text attachment was scrubbed...
Name: jlpoole56.vcf
Type: text/x-vcard
Size: 173 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120703/48f4388f/attachment.vcf>

From gpittman at iglou.com  Wed Jul  4 12:03:46 2012
From: gpittman at iglou.com (Gregory Pittman)
Date: Wed, 04 Jul 2012 08:03:46 -0400
Subject: [scribus-dev] [Cross Post]Version 1.5svn build for Windows?
In-Reply-To: <4FF3E054.5050809@gmail.com>
References: <4FF35B03.60902@gmail.com> <4FF3E054.5050809@gmail.com>
Message-ID: <4FF43122.6070909@iglou.com>

On 07/04/2012 02:19 AM, John L. Poole wrote:
> This inquiry, originally posted to the general Scribus list,
> should have been posted to this developer's list... I had
> forgotten there were two lists.  My apologies for cross posting.
> 
> ----------------------
> 
> I've been tackling building the current high watermark, 1.5svn, on
> Windows 7 and have been weighed down on getting the dependencies. For
> example, I'm using VC++ 10, not 8.  I'm keeping meticulous notes (which
> takes time) against the included build instructions as I go along so
> eventually they'll be an Idiot's Guide to Compiling Scribus for Windows
> (yes, it's an ironic title).
> 
> In the meantime, who has been successfully compiling the HEAD version on
> Windows?  Or is the build without regard to keeping it Windows
> compile-ready at this time? Is there only one person who makes the
> Windows build?
> 
> If there are major stumbling blocks that await me, I'd sure like to know
> about it.
> 
> What would be really nice to have is a current build of Scribus that
> follows HEAD -- I'm hoping I might offer that.
> 

You may already know everything here, but here is an aging wiki article
about building on Windows:

http://wiki.scribus.net/canvas/Building_Scribus_on_Windows

Greg


From ale.comp_06 at xox.ch  Thu Jul  5 22:36:47 2012
From: ale.comp_06 at xox.ch (ale rimoldi)
Date: Fri, 6 Jul 2012 00:36:47 +0200
Subject: [scribus-dev] state of the art of table, from a tester pov
In-Reply-To: <js1ugt$vol$1@dough.gmane.org>
References: <js1ugt$vol$1@dough.gmane.org>
Message-ID: <20120706003647.633d4b95@eiseiseis>

hi

> Following previous year GSOC, tables have been refactored into 1.5svn.
> 
> This mail is a global "how it is now" report from a tester point of
> view.
> 
> Some of it has to be considered as a bug description, some other part
> might be considered as an incent to improve how things work, and some
> other parts might be used so as to start a documentation.
> 
> ===============================================
> 
> Change size of column or arrow :
> - insert carret inside one of the cells in edit mode (double click)
> - bring mouse over one of the lines inside or border outside (except
> left or top borders) of the table: it changes into a double arrow.
> Then : click and drag enables to move that border or line and change
> width or height of that cell / column
> 
> =================================
> 
> Cell selection :
> is uncommon and takes some time to understand.
> - insert carret into one of the cell in edit mode (double click)
> - bring mouse over external LEFT border or TOP border of the table :
> it changes into an single arrow
> - click and gently drag : all cells betwen insert carret and the line
> where you have clicked get selected.
> - go on moving the mouse : the selection changes according to mouse
> position. It is thus possible to select any rectangular group of
> cells, including single cells. However this behaviour is uncommon.
> Expected = usual behaviour would have been to select the whole
> arrow / column when singleclicking.
> 
> Another way to select a set of cells is :
> - go out of edit mode and select the table frame, or place the edit
> carret in one of the cells you dont want to select
> - double-click-and-drag until you select the desired set of cells
> 
> ==============================
> 
> Table & frame adjust
> 
> - adjusting the table is possible without changing the frame. It is
> thus possible to make the table smaller or wider than the frame (if
> wider it is partly hiden). So the User Experience is that both frame
> and table size are independant.
> - BUT changing the frame automatically resizes the table to fit the
> new frame size, even if the table previous size was very different to
> the frame's size. This contradicts the user's previous experience of
> having tables and frames independant sizes.
> 
> I suggest that this 2nd behavious should be changed to either :
> - frame size changes do not change table size
> or :
> - frame size changes do change table size ONLY IF table size is full
> frame size. or :
> - This behavious could maybe be altered using a new option in the
> style of a table (and thus in the edit style window AND in the PP or
> context menu), with a checkbox for : "allways adjust frame to table
> and table to frame"
> 
> 
> ==============================
> 
> Table split :
> 
> i could merge 2 cells but could never have the "split cells" option
> active in the context menu (its allways greyed). (even on a
> previously merged cell).
> 
> ==============================
> 
> Action on a set of selected cells
> 
> Once a set of cells is selected it is possible through the PP to
> change the width and color of the borders of the cell and to change
> the fill color BUT
> - only the first (top left) cell is affected (the other selected
> cells dont change at all)
> - when selecting another cell, it seems the PP doesnt allways update
> its display as for the cell style
> 
> - it seems that : when the shape of the frame has been changed into
> something not rectangle, the lines that are totally outside the shape
> of the frame are displayed when coloured (but not the parts outside
> frame of lines that are only partly inside frame).
> 
> - i understood that each cell can define its borders. since an inside
> line has 2 bording cells, it can be defined in 2 different ways. When
> conflicting, it is the widest border definition that wins and totally
> overwrite the other.
> 
> - the cursor keeps being an insert carret when moved to the PP. that
> is troubling.
> 
> I posted this too in http://bugs.scribus.net/view.php?id=10784


while i was preparing the talk on scribus 1.6 for the rmll
(http://rmll.info),  i've gone through the tables and can confirm most
of the issues jluc encountered...

i've created one ticket for each issue...

ciao
a.l.e


From gpittman at iglou.com  Thu Jul  5 23:50:01 2012
From: gpittman at iglou.com (Gregory Pittman)
Date: Thu, 05 Jul 2012 19:50:01 -0400
Subject: [scribus-dev] state of the art of table, from a tester pov
In-Reply-To: <20120706003647.633d4b95@eiseiseis>
References: <js1ugt$vol$1@dough.gmane.org> <20120706003647.633d4b95@eiseiseis>
Message-ID: <4FF62829.2060604@iglou.com>

On 07/05/2012 06:36 PM, ale rimoldi wrote:

> while i was preparing the talk on scribus 1.6 for the rmll 
> (http://rmll.info), i've gone through the tables and can confirm most 
> of the issues jluc encountered...

Indeed. I was thinking of beginning some documentation on the new Table 
function, but found it so unusable that It isn't worth the bother at 
this time. I would not recommend that anyone try tables out in 1.5.0 at 
this time.

Some elemental things I find:

The cells are only usable for text and in a manual way. You cannot Get 
Text for them, you cannot Ctrl-V to them, only type manually. You cannot 
apply a Paragraph style to an individual cell or to the table as a 
whole. I think at this point having a Table tab in Properties is wasted 
space, since it really doesn't do much of anything, and doesn't avoid 
the need to (mostly) use the context menu. Tables are probably a perfect 
instance of the value of a free-floating dialog for tables.

What is working is applying justification, columns, distances, various 
text features, all manually, and cell-by-cell.

Ideally, I think a cell should function or virtually function like a 
frame, so that you could transfer the contents of a text frame to a 
cell. So that you could tear it apart and have the cells separated from 
each, yet still having table settings and characteristics. So that you 
could convert a cell to an image frame. An alternative might be to 
insert a frame/glue into a cell, so that if you change the dimensions of 
the cell, you change the dimensions of the internal frame. We're 
seemingly a long way off from importing CSV data, let alone an Excel 
file to a table.

There is yet no way to specify the border on individual sides of a cell, 
and seemingly no way to have no border at all if that's what you would 
like. The way that the borders work is possible to figure out but rather 
"esoteric" to be kind.

I can even envision having some way to transform tables with some of the 
Path tools -- individual cells along a path, for example.

The way tables work now, we might actually do better by adding the 
ability to specify the borders of individual sides of all frames, then 
use Scripter to make a tabular arrangement of a number of frames.

Greg


From jlpoole56 at gmail.com  Fri Jul  6 15:09:32 2012
From: jlpoole56 at gmail.com (John L. Poole)
Date: Fri, 06 Jul 2012 08:09:32 -0700
Subject: [scribus-dev] TIFF -- which version?
Message-ID: <4FF6FFAC.6010408@gmail.com>

I'm going through the process of building the high watermark of Scribus 
on Windows and came across an issue regarding the Tagged Image Format 
("TIFF") standard.

A dependency for Scribus is the Sourceforge color management project 
Little Color Management System.  The Scribus build notes for Windows 
suggests that the latest version of Little CMS is acceptable, so I had 
downloaded and tried to build lcms2-2.3 and ran into problems due to 
missing header files, specifically tiff_io.h.  Within package lcms2-2. 
is a reference or dependency upon TIFF 3.9.4, so the prime mover behind 
lcms, Marti Maria,is using TIFF 3.9.4 in his release.

The Windows build for Scribus specifies TIFF 3.8.2 obtainable at 
http://sourceforge.net/projects/gnuwin32/files/tiff/3.8.2/.  It appears 
that for the gnuwin32 project, their high watermark is TIFF 3.8.2.

So now there is a disparity: Scribus to date has been relying on TIFF 
3.8.2 or earlier version.  Meanwhile Little CMS has adopted a later 
version of TIFF at 3.9.4.  Add to this a third wrinkle: there appears to 
be a version 4.2 of TIFF as blessed by the OSGeo project which is 
maintaining the defunct remotesensing.org web site.

The current version of the TIFF 
(http://en.wikipedia.org/wiki/Tagged_Image_File_Format) libraries 
offered at http://www.remotesensing.org/libtiff/ (more about this site 
below) is v4.0.2 <http://www.remotesensing.org/libtiff/v4.0.2.html>

So I started doing some research on TIFF and learned that it is a 
proprietary standard developed by Aldus and now owned by Adobe.  Being 
proprietary, the TIFF standard is not subject to an open standards 
committee or such.  "It has been much long neglected" opines Joris Van 
Damme, a developer who follos TIFF 
http://www.awaresystems.be/imaging/tiff/faq.html.  There has not been 
much revision in TIFF recently, although there is a TIFFBIG 
specification which uses 64-bit offsets and thereforecan break the 4 
Gigabtye limitation of the TIFF's 32 bit offset standard.

It seems the OSGeo project comprising of over 160 companies and 
organizations has been promoting its flavor of TIFF and offers it 
through the remotesening.org site referenced above.

Then I have the question: does the library offered under the GnuWin 
project offer something unique for windows, or can the OSGeo library be 
compiled for windows.  This is something I'll find out, but I share this 
issue here in case someone has knowledge or an opinion about this.

What I'd like learn from this list are any opinions about TIFF that 
weigh against trying to incorporate the v4.0.2 into the dependencies and 
Scribus build?  It doesn't seem like much risk, but I thought I'd bring 
this issue to focus in this email to learn if there are any factors 
weighing against trying latter versions, varied they be, of TIFF.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jlpoole56.vcf
Type: text/x-vcard
Size: 164 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120706/d82ea91a/attachment.vcf>

From lrosenth at adobe.com  Fri Jul  6 15:31:36 2012
From: lrosenth at adobe.com (Leonard Rosenthol)
Date: Fri, 6 Jul 2012 08:31:36 -0700
Subject: [scribus-dev] TIFF -- which version?
In-Reply-To: <4FF6FFAC.6010408@gmail.com>
Message-ID: <CC1CCFFD.26AD4%lrosenth@adobe.com>

On 7/6/12 5:09 PM, "John L. Poole" <jlpoole56 at gmail.com> wrote:

>I'm going through the process of building the high watermark of Scribus
>on Windows and came across an issue regarding the Tagged Image Format
>("TIFF") standard.

FYI: the term "Tagged Image File Format" is never mentioned once in the
actual TIFF v6 specification.  Yes, at one time, that is what TIFF meant.,
but it's a term lost in history and not actually used in the official
documentation.


>So I started doing some research on TIFF and learned that it is a
>proprietary standard developed by Aldus and now owned by Adobe.  Being
>proprietary, the TIFF standard is not subject to an open standards
>committee or such.

TIFF has been a published specification since it was first released in the
1980's and has remained as such since 1992 when the last official version
of the specification (TIFF v6) was published by Adobe.

There are, however, various flavors of TIFF that have been standardized
(by groups such as the ISO) for use in certain vertical industries
including TIFF/IT and GeoTIFF.


>"It has been much long neglected" opines Joris Van
>Damme, a developer who follos TIFF
>http://www.awaresystems.be/imaging/tiff/faq.html.  There has not been
>much revision in TIFF recently,

Adobe has made various changes and improvements to TIFF over time, but has
done so via TechNotes.  No revised version of the full specification has
been published (for various reasons).



>although there is a TIFFBIG
>specification which uses 64-bit offsets and thereforecan break the 4
>Gigabtye limitation of the TIFF's 32 bit offset standard.

BigTIFF was released about a year ago as a joint effort between the
libTIFF group and Adobe Systems.  It is supposed by a number of vendors as
well as the libTIFF project in version 4.



>What I'd like learn from this list are any opinions about TIFF that
>weigh against trying to incorporate the v4.0.2 into the dependencies and
>Scribus build?  It doesn't seem like much risk, but I thought I'd bring
>this issue to focus in this email to learn if there are any factors
>weighing against trying latter versions, varied they be, of TIFF.

I would grab the latest version of libTIFF (4.x) and use that.


Leonard Rosenthol
Adobe Systems



From britta.yes at jubii.dk  Thu Jul 12 16:14:41 2012
From: britta.yes at jubii.dk (britta.yes)
Date: Thu, 12 Jul 2012 09:14:41 -0700
Subject: [scribus-dev] Text-formatting
Message-ID: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>

I dont understand how text-formatting works??

In InDesign the formatting dont depend of what the box is set to - in
Scribus - if I have changed 5 lines to an other font and an other size -
set a return, I go back to the box setup, and I have to get new font and
size again - crazy !

or am I doing something wrong - I have tried many many things

Dearly

britta lund

Pas p? dig selv

KH britta

N?rregade 20, 6690 G?rding . 4025 5150 


<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR><p>
INTRODUKTIONSPRIS: 250 visitkort, 50 kr. - <a href="http://ad.doubleclick.net/clk;256432360;33852900;a?http://www.vistaprint.dk/vp/gateway.aspx?S	11430132" target="_blank">klik her og se</a></p>
</font>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120712/64e62f9b/attachment.html>

From ale.comp_06 at xox.ch  Thu Jul 12 16:26:09 2012
From: ale.comp_06 at xox.ch (a.l.e)
Date: Thu, 12 Jul 2012 18:26:09 +0200
Subject: [scribus-dev] Text-formatting
In-Reply-To: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>
References: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>
Message-ID: <4FFEFAA1.2010109@xox.ch>

hi britta,
> I dont understand how text-formatting works??
>
> In InDesign the formatting dont depend of what the box is set to - in 
> Scribus - if I have changed 5 lines to an other font and an other size 
> - set a return, I go back to the box setup, and I have to get new font 
> and size again - crazy !
>
> or am I doing something wrong - I have tried many many things
at first, i wanted to tell you that you should have posted your request 
to the scribus list and not the development one (this one is the 
scribus-dev list, the list for the people interested in the development 
of scribus).



BUT:



you're not doing anything wrong...

and technically speaking, scribus is not doing anything wrong, either.

this is an issue with the way the text frame currently work in scribus 
and i'm glad that the devs see that people are going crazy because of 
this (well, i'm not glad that YOU are going crazy...)

the workardound -- as you may already have found -- is to never start 
from the first char nor from the last char.
set the pointer to the second or the one before the last one and start 
from there and then remove the extra chars
if you do this you will lose productivity, but at least you will not go 
crazy :-)


if you're interested in details i can tell you why this happens... but 
it may be tedious for you...
if somebody reading this is interested in fixing it, i can give some 
ideas on how to fix it...

let's hope that we will a much better behavior in scribus 1.6!

ciao
a.l.e


From snd.noise at gmail.com  Thu Jul 12 16:30:39 2012
From: snd.noise at gmail.com (farid abdelnour)
Date: Thu, 12 Jul 2012 13:30:39 -0300
Subject: [scribus-dev] Text-formatting
In-Reply-To: <4FFEFAA1.2010109@xox.ch>
References: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>
	<4FFEFAA1.2010109@xox.ch>
Message-ID: <CAHMxv364sqjWsXEp7A3uEn9jOpX0tMGNbmdMkg0w7QSueO9bew@mail.gmail.com>

hi

the workardound -- as you may already have found -- is to never start from
> the first char nor from the last char.
> set the pointer to the second or the one before the last one and start
> from there and then remove the extra chars
> if you do this you will lose productivity, but at least you will not go
> crazy :-)
>

hmmm, loosing productivity over a ong time makes you go crazy :P


> if you're interested in details i can tell you why this happens... but it
> may be tedious for you...
> if somebody reading this is interested in fixing it, i can give some ideas
> on how to fix it...
>

would be nice if someone picks this up :)


> let's hope that we will a much better behavior in scribus 1.6!
>

cheers

>
> ciao
> a.l.e
>
> ______________________________**_________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/**mailman/listinfo/scribus-dev<http://lists.scribus.net/mailman/listinfo/scribus-dev>
>



-- 
1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|??????
fsf member #5439
usuario GNU/Linux #471966
|_|0|_|
|_|_|0|
|0|0|0|
<a href="http://www.gunga.com.br">gunga</a>
<a href="http://www.tempoecoarte.com.br">tempoecoarte</a>
<a href="http://www.atelier-labs.org">atelier-labs</a>
<a href="http://www.mocambos.net">rede mocambos</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120712/9976cec4/attachment.html>

From gpittman at iglou.com  Thu Jul 12 23:09:19 2012
From: gpittman at iglou.com (Gregory Pittman)
Date: Thu, 12 Jul 2012 19:09:19 -0400
Subject: [scribus-dev] Text-formatting
In-Reply-To: <4FFEFAA1.2010109@xox.ch>
References: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>
	<4FFEFAA1.2010109@xox.ch>
Message-ID: <4FFF591F.2090208@iglou.com>

On 07/12/2012 12:26 PM, a.l.e wrote:
> hi britta,
>> I dont understand how text-formatting works??
>>
>> In InDesign the formatting dont depend of what the box is set to - in 
>> Scribus - if I have changed 5 lines to an other font and an other 
>> size - set a return, I go back to the box setup, and I have to get 
>> new font and size again - crazy !
>>
>> or am I doing something wrong - I have tried many many things
> at first, i wanted to tell you that you should have posted your 
> request to the scribus list and not the development one (this one is 
> the scribus-dev list, the list for the people interested in the 
> development of scribus).
>
>
>
> BUT:
>
>
>
> you're not doing anything wrong...
>
> and technically speaking, scribus is not doing anything wrong, either.
>
> this is an issue with the way the text frame currently work in scribus 
> and i'm glad that the devs see that people are going crazy because of 
> this (well, i'm not glad that YOU are going crazy...)
>
> the workardound -- as you may already have found -- is to never start 
> from the first char nor from the last char.
> set the pointer to the second or the one before the last one and start 
> from there and then remove the extra chars
> if you do this you will lose productivity, but at least you will not 
> go crazy :-)
>
>
> if you're interested in details i can tell you why this happens... but 
> it may be tedious for you...
> if somebody reading this is interested in fixing it, i can give some 
> ideas on how to fix it...
>
I used to be that there was more sensible behavior in various ways. In 
the past, if I was typing with a particular font set (Story Editor or 
Edit Contents) and pressed return, I did not have a reversion to the 
default font.
Here is some other behavior which I don't think makes sense: I start a 
new document, make a text frame, then go to File > Document Setup and 
change the default font for text frames. When I go back to the text 
frame I not only don't have my original default font, I don't have the 
new one I have chosen! Furthermore, when I then make a new text frame, 
it goes back to the original default font. Anyway you look at it, these 
behaviors shouldn't happen.

I think it starts with answering the questions about what behavior 
should be expected before someone goes and "fixes" the code, since 
they're liable to make bad choices.

Greg


From gpittman at iglou.com  Thu Jul 12 23:29:05 2012
From: gpittman at iglou.com (Gregory Pittman)
Date: Thu, 12 Jul 2012 19:29:05 -0400
Subject: [scribus-dev] Text-formatting
In-Reply-To: <4FFF591F.2090208@iglou.com>
References: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>
	<4FFEFAA1.2010109@xox.ch> <4FFF591F.2090208@iglou.com>
Message-ID: <4FFF5DC1.8060100@iglou.com>

On 07/12/2012 07:09 PM, Gregory Pittman wrote:
>
> I think it starts with answering the questions about what behavior 
> should be expected before someone goes and "fixes" the code, since 
> they're liable to make bad choices.
We've discussed this before, but I think there could be something we 
might call auto-styles, which in essence keeps a list of particular as 
yet unnamed character styles already used in a document, which might 
include font, its size, and perhaps some other features like kerning.

It would something like this. I am working in a document, highlight some 
text, or as I get ready to enter some text, I make some changes in font, 
size, etc. As soon as I have entered some text with these features, this 
gets saved as an unnamed character style, so that if I go to some other 
frame I can call up these settings without needed to create a character 
style or make the settings manually all over again.

An alternative might be to be able to go back to some text, place the 
cursor somewhere in the middle of it, and then be able to click a button 
that makes a character style from the settings at that location, without 
needing to use the Edit Styles dialog, all I have to do is to give it a 
name. Similarly, if that text already has a named character style, I see 
that name so I know what to select somewhere else. Is there a way to do 
away with the terms Default Character Style or Default Paragraph Style? 
These are very uninformative.

Greg


From ale.comp_06 at xox.ch  Fri Jul 13 05:39:46 2012
From: ale.comp_06 at xox.ch (a.l.e)
Date: Fri, 13 Jul 2012 07:39:46 +0200
Subject: [scribus-dev] Text-formatting
In-Reply-To: <4FFF591F.2090208@iglou.com>
References: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>
	<4FFEFAA1.2010109@xox.ch> <4FFF591F.2090208@iglou.com>
Message-ID: <20120713073946.6c912c55@digiteis>

hi greg,

> I used to be that there was more sensible behavior in various ways.
> In the past, if I was typing with a particular font set (Story Editor
> or Edit Contents) and pressed return, I did not have a reversion to
> the default font.
> Here is some other behavior which I don't think makes sense: I start
> a new document, make a text frame, then go to File > Document Setup
> and change the default font for text frames. When I go back to the
> text frame I not only don't have my original default font, I don't
> have the new one I have chosen! Furthermore, when I then make a new
> text frame, it goes back to the original default font. Anyway you
> look at it, these behaviors shouldn't happen.

yep, that part of the text handling is also broken.

the role of the text tool in the document setup is not clearly defined.

if you change the formatting of the text tool in the preferences, what
you get is the formatting that will be used to define the "Default
style" in the newly created document.

what should we have in the document setup? in my eyes only a drop down
where you can select which style will be applied to the newly created
frames.

everything more is just a duplicated effort :-)

what do you think about it?
i think that it would be quite easy to change that...


ciao
a.l.e


From ale.comp_06 at xox.ch  Fri Jul 13 05:41:52 2012
From: ale.comp_06 at xox.ch (a.l.e)
Date: Fri, 13 Jul 2012 07:41:52 +0200
Subject: [scribus-dev] Text-formatting
In-Reply-To: <4FFF5DC1.8060100@iglou.com>
References: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>
	<4FFEFAA1.2010109@xox.ch> <4FFF591F.2090208@iglou.com>
	<4FFF5DC1.8060100@iglou.com>
Message-ID: <20120713074152.176a8559@digiteis>

hi greg

> > I think it starts with answering the questions about what behavior 
> > should be expected before someone goes and "fixes" the code, since 
> > they're liable to make bad choices.
> We've discussed this before, but I think there could be something we 
> might call auto-styles, which in essence keeps a list of particular
> as yet unnamed character styles already used in a document, which
> might include font, its size, and perhaps some other features like
> kerning.
> 
> It would something like this. I am working in a document, highlight
> some text, or as I get ready to enter some text, I make some changes
> in font, size, etc. As soon as I have entered some text with these
> features, this gets saved as an unnamed character style, so that if I
> go to some other frame I can call up these settings without needed to
> create a character style or make the settings manually all over again.

cezary has already done some work on creating styles based on the
current selection.

i expect his code to be in 1.5svn soon :-)


ciao
a.l.e


From ale.comp_06 at xox.ch  Fri Jul 13 05:43:27 2012
From: ale.comp_06 at xox.ch (a.l.e)
Date: Fri, 13 Jul 2012 07:43:27 +0200
Subject: [scribus-dev] Text-formatting
In-Reply-To: <4FFF591F.2090208@iglou.com>
References: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>
	<4FFEFAA1.2010109@xox.ch> <4FFF591F.2090208@iglou.com>
Message-ID: <20120713074327.077d4ad7@digiteis>

hi greg,

> I think it starts with answering the questions about what behavior 
> should be expected before someone goes and "fixes" the code, since 
> they're liable to make bad choices.

well, in my eyes, the answer is not that difficult. at least not for
the most simple cases:

- if you put your cursor at the beginning of the frame (and there is
  already some text in the frame), you should get the same formatting
  as the char after the cursor
- if the cursor is at the end of the frame (and it's not an empty
  frame), the formatting of the char before the cursor should be used.
- when the frame is created (and it's empty) a default formatting
  -- defined in the document settings -- should be temporarily attached
  to the frame. it will be used when you insert the first character and
  the link will be lost.
- when you clear the content in a frame, the formatting of the last
  deleted character will be stored temporarily and attached
  to the frame. this is the formatting scribus will be using when
  a new text is typed in the text frame.
- the cases where a full last word or the full text (ctrl-a DEL) get's
  deleted at once are a bit more tricky, but i'm confident that we can
  find a good way to manage this.
- if you select the whole frame (not in edit mode) and apply some
  formatting that formatting is simply applied to the whole text in the
  frame.
- if one modifies the formatting while no text is selected, the
  formatting should be used for the next character typed; moving the
  cursor will erase those temporary formatting (or we can make them
  dependent on the position, so that if the person comes back to the
  same place the formatting will still be applied... but this might not
  be what the person expects!)

in my eyes, the biggest stepping stone is what one should see in the
properties palette when a frame is selected (while not being in edit
mode). we should probably only show the values for those formatting
that are common to the whole frame
when we are not in edit mode we could store those values in the
temporary formatting attached to the frame (with a best effort spirit:
so, if one has the whole text in red, sets one word in green and then
back (only that word) to red, the formatting for the frame will show no
color)
the major change there, would be that we would have to allow empty
values in the palette (or not applied values)


summarizing it all:
currently, there is a default style attached to the frame and this
formatting is used in several cases; in my dreams we should temporarily
attach some formatting to the frame only when it's empty.


voil?, this how i believe applying the formatting in a text frame
should behave!

if somebody wants to work on this, i can certainly start writing a more
formal specification (showing all the cases i can think of) and present
it on this list for comments!

and if you have further ideas on this, just reply to this mail! :-)

ciao
a.l.e


From britta.yes at jubii.dk  Fri Jul 13 12:43:16 2012
From: britta.yes at jubii.dk (britta.yes)
Date: Fri, 13 Jul 2012 05:43:16 -0700
Subject: [scribus-dev] text-formatting
Message-ID: <E0DDFB6C2FFC466486DD34471C6E60E6@mail2world.com>

Hello again

Thank you for alle your comments - using the second first og second last
letter is what I am using today - taking a lot of time and can get a lot
af mistakes.
One of the problems are, when I make a return and want to write more,
the text formatting go back to default.
Here is my ideas:


1.	A frame can have a default - thats OK
2.	If I wont something else - then I can either:
	- write the text an give it a style (why shall a I go two places
to use/edit styles ??) or
	- select the text an give it a direct font, size, color etc.
	and this cut the default frame set and go on with new selected
3.	A hard return gives whats defined in a style or whats defined
directly in the frame
4.	A soft return just give a new line without any change

For me it seem, it is a quistion about cutting the link back to frame
default every time a return is used, when a text is given a style og a
text is given i direct font etc.

Am I wrong ??

Hej from here

britta 


Pas p? dig selv

KH britta

N?rregade 20, 6690 G?rding . 4025 5150 


<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR><p>
INTRODUKTIONSPRIS: 250 visitkort, 50 kr. - <a href="http://ad.doubleclick.net/clk;256432360;33852900;a?http://www.vistaprint.dk/vp/gateway.aspx?S	11430132" target="_blank">klik her og se</a></p>
</font>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120713/a5a21cf1/attachment.html>

From gpittman at iglou.com  Fri Jul 13 12:53:19 2012
From: gpittman at iglou.com (Gregory Pittman)
Date: Fri, 13 Jul 2012 08:53:19 -0400
Subject: [scribus-dev] Text-formatting
In-Reply-To: <20120713074327.077d4ad7@digiteis>
References: <68170D33B1FE499290F128E023EDE1D8@mail2world.com>
	<4FFEFAA1.2010109@xox.ch> <4FFF591F.2090208@iglou.com>
	<20120713074327.077d4ad7@digiteis>
Message-ID: <50001A3F.7090904@iglou.com>

On 07/13/2012 01:43 AM, a.l.e wrote:
> hi greg,
> 
>> I think it starts with answering the questions about what behavior 
>> should be expected before someone goes and "fixes" the code, since 
>> they're liable to make bad choices.
> 
> well, in my eyes, the answer is not that difficult. at least not for
> the most simple cases:
> 
> - if you put your cursor at the beginning of the frame (and there is
>   already some text in the frame), you should get the same formatting
>   as the char after the cursor
> - if the cursor is at the end of the frame (and it's not an empty
>   frame), the formatting of the char before the cursor should be used.
> - when the frame is created (and it's empty) a default formatting
>   -- defined in the document settings -- should be temporarily attached
>   to the frame. it will be used when you insert the first character and
>   the link will be lost.
I think these are all reasonable, and hopefully not too hard to implement.


> - when you clear the content in a frame, the formatting of the last
>   deleted character will be stored temporarily and attached
>   to the frame. this is the formatting scribus will be using when
>   a new text is typed in the text frame.
> - the cases where a full last word or the full text (ctrl-a DEL) get's
>   deleted at once are a bit more tricky, but i'm confident that we can
>   find a good way to manage this.

I think both of these are more problematic conceptually.

> - if you select the whole frame (not in edit mode) and apply some
>   formatting that formatting is simply applied to the whole text in the
>   frame.
> - if one modifies the formatting while no text is selected, the
>   formatting should be used for the next character typed; moving the
>   cursor will erase those temporary formatting (or we can make them
>   dependent on the position, so that if the person comes back to the
>   same place the formatting will still be applied... but this might not
>   be what the person expects!)
> 
My suggestion for these two is to make the "Default" style more fluid.
If you change the style or font features for an entire frame, empty or
not, this should become the default for that frame until it's changed.

> when we are not in edit mode we could store those values in the
> temporary formatting attached to the frame (with a best effort spirit:
> so, if one has the whole text in red, sets one word in green and then
> back (only that word) to red, the formatting for the frame will show no
> color)

If you look at an SLA file, what you see is that each time there is some
mod to the style, it creates a new <ITEXT...> block. It might be that
improving style handling could make this less verbose.

Greg


From ale.comp_06 at xox.ch  Fri Jul 13 15:08:09 2012
From: ale.comp_06 at xox.ch (a.l.e)
Date: Fri, 13 Jul 2012 17:08:09 +0200
Subject: [scribus-dev] text-formatting
In-Reply-To: <E0DDFB6C2FFC466486DD34471C6E60E6@mail2world.com>
References: <E0DDFB6C2FFC466486DD34471C6E60E6@mail2world.com>
Message-ID: <500039D9.4080607@xox.ch>

hi britta,
> Thank you for alle your comments - using the second first og second 
> last letter is what I am using today - taking a lot of time and can 
> get a lot af mistakes.
> One of the problems are, when I make a return and want to write more, 
> the text formatting go back to default.
> Here is my ideas:
>
>  1. A frame can have a default - thats OK
>  2. If I wont something else - then I can either:
>     - write the text an give it a style (why shall a I go two places
>     to use/edit styles ??) or
>     - select the text an give it a direct font, size, color etc.
>     and this cut the default frame set and go on with new selected
>  3. A hard return gives whats defined in a style or whats defined
>     directly in the frame
>  4. A soft return just give a new line without any change
>
> For me it seem, it is a quistion about cutting the link back to frame 
> default every time a return is used, when a text is given a style og a 
> text is given i direct font etc.
>
> Am I wrong ?
>

you're at least more right than me!

the problem is currently indeed bount to the return.

to reproduce:
- put some text in a text frame
- set the color for the whole frame to green
- set the last word to red

now:
- if you type some text at the end of the frame it will be red.
- but as soon as you type return in the middle of a green word, you the 
text on the new line will be green but the one at the end of the old 
line will be red
- if you put a return at the end of the last word (a green one!), if you 
write some text at then of the old one it will be green, but on the new 
line it will be red
- if you set the first word as green and add a return in front of it, 
the text on the new line will also be red
- with shift click you don't get the problem.

do those steps match what you're experience?

ciao
a.l.e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20120713/3a6f5c9f/attachment.html>

From cbradney at scribus.info  Mon Jul 16 16:32:09 2012
From: cbradney at scribus.info (Craig Bradney)
Date: Mon, 16 Jul 2012 18:32:09 +0200
Subject: [scribus-dev] r17722 by gpittman - trial of augmented tooltips
 with shortcuts -- feedback?
In-Reply-To: <mailman.1908.1342454668.25036.scribus-commit@lists.scribus.net>
References: <mailman.1908.1342454668.25036.scribus-commit@lists.scribus.net>
Message-ID: <50044209.6030704@scribus.info>

On 7/16/12 6:03 PM, scribus-commit wrote:
>  	(*scrActions)["toolsInsertFreehandLine"]->setText( tr("Insert &Freehand Line"));
> +	(*scrActions)["toolsInsertFreehandLine"]->setToolTip( tr("Insert Freehand Line")+" <b>"+QString(defaultKey("toolsInsertFreehandLine"))+"</b>");


Hi

If we are going to need two lines, then we would do it like this:

	(*scrActions)["toolsInsertFreehandLine"]->setText( tr("Insert &Freehand Line"));
+	(*scrActions)["toolsInsertFreehandLine"]->setToolTip(
(*scrActions)["toolsInsertFreehandLine"]->text() + "
<b>"+QString(defaultKey("toolsInsertFreehandLine"))+"</b>");

to avoid 2x the translation requirement.

However, I was thinking of doing this in the scraction code itself and avoid this altogether.

Craig


From christoph-schaefer at gmx.de  Sun Jul 29 06:38:44 2012
From: christoph-schaefer at gmx.de (=?iso-8859-1?Q?=22Christoph_Sch=E4fer=22?=)
Date: Sun, 29 Jul 2012 08:38:44 +0200
Subject: [scribus-dev] Sample files from older programs for those who would
 like to re-engineer
Message-ID: <20120729063844.279460@gmx.net>

Hi,

I finally managed to install eComStation (formerly known as OS/2) in VirtualBox. Since eCS is also being shipped with a Windows 3 environment, I was able to install some really old graphics programs whose output may be of interest to those who are versed in reverse engineering.

Here's what I have found and installed in my files (gosh! how cheap these programs were back then!):

- CorelDraw (Suite) 5.0 for Windows 3
- Micrografx Designer 4.1 for Windows 3
- PageMaker 5.0 for Windows 3
- QuarkXPress 3.3 for Windows 3
- Visio 4.0 (i.e., before Visio was acquired by MS) for Windows 3

I also have IBM Works for OS/2 (the predecessor of SmartSuite) and StarOffice 5.1a for OS/2 installed.

If someone is interested in reverse-engineering the Maul Publisher file format (Maul is a desktop publishing program for OS/2 and Windows), the eComStation add-on disc comprises a demo version, so I would be able to produce sample files as well.

Since all of the files created by these programs are from the early nineties, their content is probably not as complex as the output produced by their current incarnations.

Cheers,

Christoph


