Reassigned to Bettina.

Any progress on this issue? 

Draw is almost a perfect DTP program for me, and this issue is the main thing 
that it is lacking. Since this functionality already exists in Writer, it may 
be reasonably simple to add it to Draw. Please!!! :-)

It would be a really good feature for us.

What modules within draw deals with the text frame and what would it be needed 
to have them had contiunation. 

The next question is should the Writer component for textframe merge with the 
one from draw on a similar fashion that the spreadsheet did with the writer 
tables?

Hi Christian, please take these issues to your ownership.

currently no resources to completely rework the text engine in impress,
therefore target to later

Issue 33501 is duplicate to this issue. But i33501 has got already 10 votes.
Therefore I have not closed it. Please consider that votes for this enhancement
request too.

Very much wanted feature for those who move from MS Office to OOO and get used
to Publisher already.

Any chance of this happening ever?

We´re a school and are looking for an alternative to MS Publisher for our school 
magazine. With this function Draw would be great for this. But without you can´t 
use it reasonable for creating a Magazine :( 
I guess it might be very helpful when pupils who bring interest for working with 
computers and not only playing games, get to know alternatives to MS early. 
I´m near to the point to let them all register here only to vote for this Issue. 
Cause 20 Votes in 6 Years is much too less... :(

I am also looking forward for this fix, however you can consider using Scribus
which is Free software, and compatible with OOo Draw. 

http://www.scribus.net/

However I would like to research more about the issue with the text-flow. From
my understanding is that tese textbox are more similar to the ones you will find
in Impress than the Frames from Writer. That is the main reason why a
refactoring of the way these textbox work would be necesary.

Scribus have a different serious bug that makes it hardly usable in Asian
context, Chinese, Japanese and Korean languages:
http://bugs.scribus.net/view.php?id=3928

It's obvious the scribus bug, reported 4 years ago, require much more changes to
solve their problem. Yet attentions obtained on their side for the issue is much
less than OOO because scribus have a narrower audience of industrial users
compare to OOO having a broader audience of consumer market. Thus it's
reasonable I expect this OOO feature request being fixed ahead of that scribus
bug report.

...

Please collect more votes for this, as those who need this feature are unlikely
heavy participant of OOO bug tracker thus I believe vote has been biased. 
(compare to other features like SVG support, that those who need that feature
are likely happen to be heavy participant of OOO bug tracker.)

@zhangweiwu 

The only way to "Collect more votes" for this issue is for you to promote this issue among people who 
can and will vote.

Post appeals to the OOo user list, the discuss list, message boards, etc..

I've had my 2 votes (which is as many as I can give) on this issue for years now.

You can also talk to people who currently can't / don't vote and let them know about the issue.  Have 
them create an account (you may have to walk them through the process) and then show them how to 
vote, and where the issue is.

That being said, having a high number of votes does not guarantee that it will be fixed, nor does having 
a low number of votes mean it will be ignored.  All the votes do is give some sort of indication as to how 
people who may not be able to program feel about a given issue.

The only way to guarantee that an issue will be fixed is to fix the problem - either by doing the code 
work yourself, (which, like many OOo users, is not a possibility for me), or paying / convincing someone 
who can code to do the work for you, (or - a better appeal would be - for all the Asian users who need 
this the most).

@jza

From my understanding, the way OOo works overall is that it is a single unified program with various 
"modes".  Unlike, say Micorosoft Office, which is actually several different programs that are just 
bundled together.  Whether you open Impress or Draw or Writer - the actual program you are opening is 
the same (OpenOffice.org - staroffice.exe on the Windows task manager, last I checked).

What this implies to me, (and, again, I'm no programmer, and I don't know these things for certain), is 
that they could just "flip a switch" in the code and use the Frames from Writer in the Draw "mode".  I'm 
sure it's a bit more complicated than that - but the idea is that what works in mode A should be able to 
work in mode B, since it's the same program that's actually running.

However, I noticed the differences in the words being used (Text boxes vs. Frames).  And that might be 
the issue.  What may actually have to be done is the way Text Boxes work in all the modes would have 
be redone (so Text Flow would work in Impress or Draw, etc. - and you could use Text Boxes in Writer).  
That would be a far more difficult task, I imagine, than my previous "flip of a switch".

That would, IMHO, be the best solution anyway.  To have a unified Text Flow enabled Text Box for any 
and all the modes.  It would really improve OOo, and give it a clear advantage over other office apps.

Hi. The attitude is not new to me, I know the method you are talking about.

There are users who don't know their problem good enough to actually propose
what should have been done. These user vote with their feet and is the "96%
silent consumers" referred to marketing people.

And there are who knows what they are dealing and promptly ask for their needs.
Or, the "4% smart customers".

Respond-development model make product lean towards 4% smart customers.

The typical OSS community attitude is not to approach users who don't subscribe
mailing-list and rather try different product instead of "asking the question
the smart way", rather instead, try convert these users to participate community
and abandon those who cannot.

"I usually like the OSS community approach because since my ego told me I am the
smartest person in the world, I should only like to talk with smart guys:)"

No, I don't mean that:) What I really mean is we should weight the opinion of
the people who don't talk instead of getting them here.

> What I really mean is we should weight the opinion of
> the people who don't talk instead of getting them here.

Don't get me wrong, I also kept trying to convince people to work 
with OOO community on lists/bug reports, for the last a few years:)

@chadley78: unfortunately, in this case, it's not just flipping a switch, but a
plainly missing feature in the code that handles the Draw text.

Quoting zhangweiwu, "we should weight the opinion of the people who don't talk instead of getting 
them here."

The problem with that is, it's pretty much impossible to do accurately.  People who don't vote don't have 
a voice.  That's true in democratic governments, and it's true here.  You could easily say "I talked to 50 
people, and all of them wanted this issue fixed." - And you could be completely honest in saying that.  
But then someone else could say "Well, I talked to 50  people, and they'd rather have SVG import than 
Text flow text boxes."  Which issue gets the votes?  Do they both get 50 extra votes?

What about all the other issues that people would like to see, but don't know how to vote for.

The fact of the matter is - every issue (or, nearly every issue) - would have many, many times more 
votes than they do now if we somehow got opinions from every human being on the planet.  Orders of 
magnitude more.  It wouldn't be 20 votes anymore - it wouldn't be 200, or 200,000 - it would likely be 
in the millions or hundreds of millions.

However, we can't do that.  Not everyone in the world cares about text boxes.  Not everyone in the world 
cares about OpenOffice.org.  Not everyone in the world cares about computers (as hard as that is to 
believe).  And even for the millions of "Silent users" - we can't presume to speak on their behalf.

The only way to know for sure what people want is to have them vote.  It's not a perfect system.  But it 
does reflect the feelings of those who (A) know what they want (B) care enough to learn how to vote and 
(C) care enough to vote.

Is that fair?  Not necessarily.  But, again - even if we did somehow accurately get opinions from every 
single user of OpenOffice.org - even if we somehow weighted those opinions by time of use, expertise 
of the user, or whatever you want to use to weight them.  Even if we could tear back the language 
barriers, technical mumbo jumbo, and actually accurately see what everyone really truly wanted....  That 
would not necessarily mean this particular problem would ever get fixed.  Even if this was the #1 
priority by far from every user in the world.  It doesn't mean it is the priority of anyone who can actually 
make it happen.

This is an open source project.  It's not a democracy.  It's not even respond-based.  It is completely up 
to the individual coders who want to fix it.  No one can force volunteers to complete a certain task.  If 
they don't want to do it, they won't.

Now, Sun - or Oracle I guess it is now - and Google (if they are still involved) and maybe some other 
companies have paid programmers who work on OpenOffice.org.  The companies can set agendas for 
their coders.  But, again, their priorities may or may not have anything whatsoever to do with the 
number of votes on the issue tracker.

So - are votes useless?  Ultimately, yes, I think they are.  And that's based on years of having my votes 
on the same issues - and none of them getting fixed.

But they may give some motivation to people who choose to work on the code.  It may sway their 
decision one way instead of the other - so it's not completely pointless.  But it is certainly no guarantee 
of anything whatsoever.

@chadley78 
I understand what you are trying to say here, unfortunately from my research is
not like that. 

If you go into writer, and go to View -> Toolbars -> Drawing = Text boxes, you
can have the same non-connected areas.

So I think it would be less coding to just import frames in draw rather than
having Textboxes replicate what frames do. 

Again if you want to see the code you can check out here:
http://api.openoffice.org/docs/common/ref/com/sun/star/drawing/TextShape.html
and the frames here:
http://api.openoffice.org/docs/common/ref/com/sun/star/text/AccessibleTextFrameView.html

Is two completely different implementations one depending from "drawing module"
and the other from "text module".

Probably a more expert developer can comment on these differences as far as
implementing this goes.

Also please copy your comments to dev@openoffice.org to have more attention from
devs.

*** Issue 33501 has been marked as a duplicate of this issue. ***

In fact we need that text in a form goes automaticaly into antother attached form, like in Publisher, to import correctly Publisher files. I can't use Libreoffice rather than Microsoft office because I can't use my .Pub files. When importing Publisher files, it would be grat that form attachments are respected.

I will promote this as a GSOC task.

*** Issue 35897 has been marked as a duplicate of this issue. ***

Reset the assignee to the default "issues@openoffice.apache.org".