This is Umbrello version 2.10.0, could not choose that from the list.

I have the same problem in two machines:

Umbrello 2.10.1
openSUSE 12.3 - 64 bits
KDE 4.10.1

Umbrello 2.10.0
openSUSE 12.3 - 32 bits
KDE 4.10.0

Looks like a real bug... Please fix it.

Export doesn't work for me either. I kept trying this feature since Fedora 17 (current release is 19) on two systems with no success. I'm using the latest Umbrello from the Fedora repository (2.10.5).

Exporting from the menu gives an error: 
"An error happened when exporting the image:
A problem occurred while saving diagram in /tmp/aaa.jpg."

I also tried exporting to every format supported from the shell:
$ for F in  `umbrello --export-formats 2> /dev/null `; do umbrello --export $F hrservice.xmi; done

None of the exported formats work, some are incomplete, others have misplaced objects and some are just unreadable.

 Please let me know if you require more information.

To see if the there are permission errors on creating file  you may run umbrello with 

strace umbrello ..... 2>&1 | grep open 

to see a list of opened files and possible return errors. 

If you cannot find something unusual you may start kdebugdialog, search for umbrello and enable all umbrello related messages. 
Then run umbrello from command line, which will produce debug messages. 
If you do not find any related messages you may start kdebugdialog again and additional enable  kio/kdelibs related debug messages. 

If this do not help to get an idea what's going wrong, you may compile umbrello in debug mode an run umbrello under a debugger. I made good experience with qt creator.

Created attachment 82361 [details]
original file, export log and generated files

Thank you Ralph for your quick response.

I did, as advised, a "strace umbrello --export jpg t.xmi 2>&1 | grep open". Nothing suspicious, all files can be written to.

I attached the output generated by the command: "umbrello --export jpg t.xmi 2>&1" (with umbrello related messages enabled in kdedebugdialog) and two generated jpg files. There are a lot of "Painter not active" messages in the log, maybe that is the problem.

Created attachment 82455 [details]
Fix mapping of file extension to mime type

This bug was introduced in commit 7e6729ba. When selecting JPEG for example, the argument for UMLViewImageExporterModel::imageTypeToMimeType() is a string containing all possible file extensions (jpg, jpeg) while the imageTypeToMimeType method expects only one extension.

Attached patch allows this by matching the main file type and ignoring any leading/trailing extensions.

(In reply to comment #6)
> Created attachment 82455 [details]
> Fix mapping of file extension to mime type
> 
Thanks for your effort. 
After digging into this stuff I come to the conclusion, that this bug seems to be have other reasons, because UMLViewImageExporterModel::imageTypeToMimeType() is intended to process one image type, not multiple. 

/**
 * Returns the mime type for an image type.
 * The supported image types are those that the diagrams can be exported to.
 *
 * @param imageType The type of the image.
 * @return A QString with the equivalent mime type, or QString() if
 *         it's unknown.
 */
QString UMLViewImageExporterModel::imageTypeToMimeType(const QString& imageType)

instead there is a misconception in  UMLViewImageExporter::getParametersFromUser() mentioned below: 

/**
 * Shows a save file dialog to the user to get the parameters used
 * to export the view and updates the attributes with the parameters got.
 *
 * @return True if the user wants to save the image,
 *         false if the operation is cancelled.
 */
bool UMLViewImageExporter::getParametersFromUser()
{
    bool success = true;

    // configure & show the file dialog
    KUrl url;
    QPointer<UMLFileDialog> dialog = new UMLFileDialog(url, QString(), UMLApp::app());
    prepareFileDialog(dialog);
    dialog->exec();

-> dialog has been executed and closed 

    if (dialog->selectedUrl().isEmpty()) {
        success = false;
    }
    else {
        m_scene->clearSelected();   // Thanks to Peter Soetens for the idea

        // update image url and mime type
        m_imageMimeType = dialog->currentMimeFilter();

--> this should return the mime type of the selected file. 

In the called method which handles a single mimetype

QString UMLFileDialog::currentMimeFilter()
{
    QString currentFilter = m_dialog->currentFilter();

this return multiple filters instead of the one of the selected file. 

    #ifdef Q_OS_WIN
    // using native KFileDialog returns empty filter, so we need a workaround
    if (currentFilter.isEmpty()) {
        KUrl url = m_dialog->selectedUrl();
        QFileInfo fi(url.toLocalFile());
        return UMLViewImageExporterModel::imageTypeToMimeType(fi.suffix());

On windows where the native KFileDialog is used it works correctly. 

    }
    #endif
    return UMLViewImageExporterModel::imageTypeToMimeType(currentFilter.remove("*."));
}

... returning to bool UMLViewImageExporter::getParametersFromUser()

        // update image url and mime type
        m_imageMimeType = dialog->currentMimeFilter();

        UMLApp::app()->setImageMimeType(m_imageMimeType);

the returned (single) mimetype is set as default 

/**
 * Sets the default mime type for all diagrams that are exported as images.
 * @param mimeType   the mime type
 */
void UMLApp::setImageMimeType(const QString& mimeType)


then the url of the selected file is taken 

        m_imageURL = dialog->selectedUrl();


and ...         // check if the extension is the extension of the mime type
        QFileInfo info(m_imageURL.fileName());
        QString ext = info.suffix();
        QString extDef = UMLViewImageExporterModel::mimeTypeToImageType(m_imageMimeType);
        if (ext != extDef) {
            m_imageURL.setFileName(m_imageURL.fileName() + '.' + extDef);

which takes always the extension based on the mime type of the selected file extension and not the one returned from currentMimeFilter() ... this looks as something that could be simplified. 

Returning to the main problem: the usage of dialog->currentMimeFilter(); has been introduced  with 

commit 13e7b715b4e01f9b18d06d8998278c43c9b07eb4
Date:   Sun Apr 2 10:29:29 2006 +0000

    Apply attachment 15388 [details] by Daniel Calviño Sánchez with minor changes.
    CCBUG:58809

which was at kde3 times. May be that the meaning of currentMimeFilter() has been changed in the transition from kde3 to kde4.

At least we're getting somewhere :)

In reply to your comment: imageTypeToMimeType() is still handling one file type per invocation.

The culprit is one filter can now contain multiple file extensions ("*.jpeg *.jpg *.jpe *.jfif" - the KMimeType pattern). So for the PNG files, all is fine ("*.png" -> "png" == "png"), but JPEG fails ("*.jpeg *.jpg" -> "jpeg jpg" != "jpg") hence checking for contains("jpg") will make everything work as intended.

I agree there must be a better way of mapping the selected filter back to a mime-type.

(In reply to comment #8)
> At least we're getting somewhere :)
> 
> In reply to your comment: imageTypeToMimeType() is still handling one file
> type per invocation.
> 
> The culprit is one filter can now contain multiple file extensions ("*.jpeg
> *.jpg *.jpe *.jfif" - the KMimeType pattern). So for the PNG files, all is
> fine ("*.png" -> "png" == "png"), but JPEG fails ("*.jpeg *.jpg" -> "jpeg
> jpg" != "jpg") hence checking for contains("jpg") will make everything work
> as intended.
> 
I see, thanks for explanations. 

> I agree there must be a better way of mapping the selected filter back to a
> mime-type.

What about to refactor UMLFileDialog::currentMimeFilter() to something like 
/**
 * @brief return the mime type of the currenty selected file
 * @return mime type string
 */
QString UMLFileDialog::currentMimeFilter()
{
    KUrl url = m_dialog->selectedUrl();
    QFileInfo fi(url.toLocalFile());
    return UMLViewImageExporterModel::imageTypeToMimeType(fi.suffix());
}

which is already the default case on windows ?

(In reply to comment #9)
> (In reply to comment #8)
> > At least we're getting somewhere :)
> > 
> > The culprit is one filter can now contain multiple file extensions ("*.jpeg
> > *.jpg *.jpe *.jfif" - the KMimeType pattern). So for the PNG files, all is
> > fine ("*.png" -> "png" == "png"), but JPEG fails ("*.jpeg *.jpg" -> "jpeg
> > jpg" != "jpg") hence checking for contains("jpg") will make everything work
> > as intended.
+
+    // imageType is a list of one or more possible file extensions
+    // for a selected file type, for example:
+    //   Bitmap: "bmp dib"
+    //   JPEG:   "jpeg jpg"
+    //   PNG:    "png"
... 
+    if (imgType.contains("jpeg")) return "image/jpeg";
there is still no "jpg" handling case

Ralf, comment #8 makes sense. I can confirm that works as expected.

Sorry, I was talking about comment #9, not comment #8!

Git commit 4f4a296c341a2f5e7d74d8ef5702aa7c53da107d by Ralf Habacker.
Committed on 24/09/2013 at 11:02.
Pushed by habacker into branch 'master'.

Cleanup of mime type detection when exporting bitmaps.

The usage of KDE4's KFileDialog::currentMimeFilter() is broken,
because it returns a list of the currently selected file type.
In the opposite the code expects a single mime type of the selected file.

M  +7    -10   umbrello/dialogs/umlfiledialog.cpp
M  +0    -8    umbrello/umlviewimageexporter.cpp

http://commits.kde.org/umbrello/4f4a296c341a2f5e7d74d8ef5702aa7c53da107d

Git commit b5ec972bfec691a4a68530431e5d92acb8aeb8d7 by Ralf Habacker.
Committed on 24/09/2013 at 11:02.
Pushed by habacker into branch 'KDE/4.11'.

Cleanup of mime type detection when exporting bitmaps.

The usage of KDE4's KFileDialog::currentMimeFilter() is broken,
because it returns a list of the currently selected file type.
In the opposite the code expects a single mime type of the selected file.
FIXED-IN:4.11.3

M  +7    -10   umbrello/dialogs/umlfiledialog.cpp
M  +0    -8    umbrello/umlviewimageexporter.cpp

http://commits.kde.org/umbrello/b5ec972bfec691a4a68530431e5d92acb8aeb8d7

*** Bug 327046 has been marked as a duplicate of this bug. ***

*** Bug 139908 has been marked as a duplicate of this bug. ***