View Revisions: Issue #11420

Summary 0011420: 1.5 style management during page import
Revision 2015-10-30 18:42 by JLuc
Description [EDIT] The same issue exists when
- copying an object in a document and paste it in another document
- placing an object in the scrapbook and paste it in another document
- importing some page(s) from some other document (0011814)

1.4 tried to cleverly manage styles during a page import - but code was not finished and functionnality was buggy. 1.5 is different but does not better at it.

Uploaded pageimport.sla is a document featuring 3 paragraph :

- A paragraph with pure "default par style" being defined as CYAN ARIAL UPPERCASE. When imported it keeps being "default par style" but the definition is not imported and so the look is correct.

- A paragraph with "default par style" and some local inline character formating (not using style definitions) : this is perfectly imported.
This paragraph includes also a bit of text styled with a named char style : "UserCharStyle". This part of text cannot be read once imported : all letters appear as big squares. + The named style has not been created in the importing document. There must be some big mismatch in the styles defintion and uses.

- A paragraph with a pure user defined paragraph style : UserParStyle, that does not formerly exists in the importing document. It includes both character properties : color, font, effects and paragraphe properties : lineheights.
Strangely, the paragraph looks partly well : color , lineheight, font and font size are ok but "uppercase" text effect has been lost.

- At first it looks like the imported styles have not been created in the document since they dont appear in the style window, but its only a display refresh issue because 2 newly created styles appear sooner or later in the style dialog : a new "default paragraph style" (that make 2 styles with same name; that's a problem) and the imported "UserParStyle".
The defined and used character style has not been imported at all.

- When looking more closely at the UserParStyle, it looks like
1) some of its properties have been copied truthfully (font, lineheight...)
2) some of its properties have been totally ignored (uppercase)
3) for the color of the font, its more complex. At first it appears to NOT have been copied into the style definition, but into the text itself, as inline formatting. But then later on, after some operations, it seems to appears that the style definition sometime changes itself to reflect the original style value.

That's a big lot of important issues that make the functionnality rather hazardous to use.
Revision 2015-10-30 18:40 by JLuc
Description [EDIT1] - Also reported by Gary Dale in debian bug system : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800778 [^]

[EDIT2] The same issue exists when
- copying an object in a document and paste it in another document
- placing an object in the scrapbook and paste it in another document
- importing some page(s) from some other document (0011814)

1.4 tried to cleverly manage styles during a page import - but code was not finished and functionnality was buggy. 1.5 is different but does not better at it.

Uploaded pageimport.sla is a document featuring 3 paragraph :

- A paragraph with pure "default par style" being defined as CYAN ARIAL UPPERCASE. When imported it keeps being "default par style" but the definition is not imported and so the look is correct.

- A paragraph with "default par style" and some local inline character formating (not using style definitions) : this is perfectly imported.
This paragraph includes also a bit of text styled with a named char style : "UserCharStyle". This part of text cannot be read once imported : all letters appear as big squares. + The named style has not been created in the importing document. There must be some big mismatch in the styles defintion and uses.

- A paragraph with a pure user defined paragraph style : UserParStyle, that does not formerly exists in the importing document. It includes both character properties : color, font, effects and paragraphe properties : lineheights.
Strangely, the paragraph looks partly well : color , lineheight, font and font size are ok but "uppercase" text effect has been lost.

- At first it looks like the imported styles have not been created in the document since they dont appear in the style window, but its only a display refresh issue because 2 newly created styles appear sooner or later in the style dialog : a new "default paragraph style" (that make 2 styles with same name; that's a problem) and the imported "UserParStyle".
The defined and used character style has not been imported at all.

- When looking more closely at the UserParStyle, it looks like
1) some of its properties have been copied truthfully (font, lineheight...)
2) some of its properties have been totally ignored (uppercase)
3) for the color of the font, its more complex. At first it appears to NOT have been copied into the style definition, but into the text itself, as inline formatting. But then later on, after some operations, it seems to appears that the style definition sometime changes itself to reflect the original style value.

That's a big lot of important issues that make the functionnality rather hazardous to use.
Revision 2015-10-16 15:06 by JLuc
Description [EDIT1] - Also reported by Gary Dale in debian bug system : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800778 [^]

[EDIT2] The same issue exists when
- copying an object in a document and paste it in another document
- placing an object in the scrapbook and paste it in another document
- importing some page(s) from some other document

1.4 tried to cleverly manage styles during a page import - but code was not finished and functionnality was buggy. 1.5 is different but does not better at it.

Uploaded pageimport.sla is a document featuring 3 paragraph :

- A paragraph with pure "default par style" being defined as CYAN ARIAL UPPERCASE. When imported it keeps being "default par style" but the definition is not imported and so the look is correct.

- A paragraph with "default par style" and some local inline character formating (not using style definitions) : this is perfectly imported.
This paragraph includes also a bit of text styled with a named char style : "UserCharStyle". This part of text cannot be read once imported : all letters appear as big squares. + The named style has not been created in the importing document. There must be some big mismatch in the styles defintion and uses.

- A paragraph with a pure user defined paragraph style : UserParStyle, that does not formerly exists in the importing document. It includes both character properties : color, font, effects and paragraphe properties : lineheights.
Strangely, the paragraph looks partly well : color , lineheight, font and font size are ok but "uppercase" text effect has been lost.

- At first it looks like the imported styles have not been created in the document since they dont appear in the style window, but its only a display refresh issue because 2 newly created styles appear sooner or later in the style dialog : a new "default paragraph style" (that make 2 styles with same name; that's a problem) and the imported "UserParStyle".
The defined and used character style has not been imported at all.

- When looking more closely at the UserParStyle, it looks like
1) some of its properties have been copied truthfully (font, lineheight...)
2) some of its properties have been totally ignored (uppercase)
3) for the color of the font, its more complex. At first it appears to NOT have been copied into the style definition, but into the text itself, as inline formatting. But then later on, after some operations, it seems to appears that the style definition sometime changes itself to reflect the original style value.

That's a big lot of important issues that make the functionnality rather hazardous to use.
Revision 2013-02-13 19:31 by JLuc
Description 1.4 tried to cleverly manage styles during a page import - but code was not finished and functionnality was buggy. 1.5 is different but does not better at it.

Uploaded pageimport.sla is a document featuring 3 paragraph :

- A paragraph with pure "default par style" being defined as CYAN ARIAL UPPERCASE. When imported it keeps being "default par style" but the definition is not imported and so the look is correct.

- A paragraph with "default par style" and some local inline character formating (not using style definitions) : this is perfectly imported.
This paragraph includes also a bit of text styled with a named char style : "UserCharStyle". This part of text cannot be read once imported : all letters appear as big squares. + The named style has not been created in the importing document. There must be some big mismatch in the styles defintion and uses.

- A paragraph with a pure user defined paragraph style : UserParStyle, that does not formerly exists in the importing document. It includes both character properties : color, font, effects and paragraphe properties : lineheights.
Strangely, the paragraph looks partly well : color , lineheight, font and font size are ok but "uppercase" text effect has been lost.

- At first it looks like the imported styles have not been created in the document since they dont appear in the style window, but its only a display refresh issue because 2 newly created styles appear sooner or later in the style dialog : a new "default paragraph style" (that make 2 styles with same name; that's a problem) and the imported "UserParStyle".
The defined and used character style has not been imported at all.

- When looking more closely at the UserParStyle, it looks like
1) some of its properties have been copied truthfully (font, lineheight...)
2) some of its properties have been totally ignored (uppercase)
3) for the color of the font, its more complex. At first it appears to NOT have been copied into the style definition, but into the text itself, as inline formatting. But then later on, after some operations, it seems to appears that the style definition sometime changes itself to reflect the original style value.

That's a big lot of important issues that make the functionnality rather hazardous to use.